Mercurial > sdl-ios-xcode
view test/automated/README @ 5082:de59e0218aa2
Fixed bug #1011
Daniel Ellis 2010-06-25 15:20:31 PDT
SDL based applications sometimes display the wrong application name in the
Sound Preferences dialog when using pulseaudio.
I can see from the code that the SDL pulse module is initiating a new pulse
audio context and passing an application name using the function
get_progname().
The get_progname() function returns the name of the current process. However,
the process name is often not a suitable name to use. For example, the OpenShot
video editor is a python application, and so "python" is displayed in the Sound
Preferences window (see Bug #596504), when it should be displaying "OpenShot".
PulseAudio allows applications to specify the application name, either at the
time the context is created (as SDL does currently), or by special environment
variables (see http://www.pulseaudio.org/wiki/ApplicationProperties). If no
name is specified, then pulseaudio will determine the name based on the
process.
If you specify the application name when initiating the pulseaudio context,
then that will override any application name specified using an environment
variable.
As libsdl is a library, I believe the solution is for libsdl to not specify any
application name when initiating a pulseaudio context, which will enable
applications to specify the application name using environment variables. In
the case that the applications do not specify anything, pulseaudio will fall
back to using the process name anyway.
The attached patch removes the get_progname() function and passes NULL as the
application name when creating the pulseaudio context, which fixes the issue.
author | Sam Lantinga <slouken@libsdl.org> |
---|---|
date | Sun, 23 Jan 2011 21:55:04 -0800 |
parents | 22ac66da0765 |
children |
line wrap: on
line source
SDL Automated Testing Framework User Documentation by Edgar Simo Serra Abstract The SDL Automated Testing Framework, hereby after called SDL_AT, is a meant to test the SDL code for regressions and other possible failures. It can also be used to display what your SDL set up supports. Basics The main way to use the framework is to compile it and run it, that can be done with the following command: $> make test It should then display something like: Platform : All tests successful (2) SDL_RWops : All tests successful (5) SDL_Surface : All tests successful (6) Rendering with x11 driver : All tests successful (4) Indicating that all tests were successful. If however a test fails output it will report the failure to stderr indicating where and why it happened. This output can then be sent to the developers so they can attempt to fix the problem. Advanced By passing the "-h" or "--help" parameter to testsdl you can get an overview of all the possible options you can set to furthur tweak the testing. A sample of the options would be the following: Usage: ./testsdl [OPTIONS] Options are: -m, --manual enables tests that require user interaction --noplatform do not run the platform tests --norwops do not run the rwops tests --nosurface do not run the surface tests --norender do not run the render tests -v, --verbose increases verbosity level by 1 for each -v -q, --quiet only displays errors -h, --help display this message and exit Developers See SDL_at.h for developer information.