I’ve found several bugs related to sounds (mostly in DirectGui), and I also want to know whether I can easily configure DirectGui to have all gui widget sounds off by default.
(I’m using a recent development snapshot on Mac OS 10.7 (Lion), but I think none of this has changed since 1.7.2.)
Bugs:
The manual says the default sound library is OpenAL (not Fmod), and the comment in Config.prc where this is defined also says this, but the actual assignment line sets it to Fmod:
Enable audio using the OpenAL audio library by default:
audio-library-name p3fmod_audio
This is either a bug in the manual and in that comment line, or a bug in the default setting. (I’d favor thinking of it as a bug in the default setting, due to the Fmod licensing fees. If it’s a platform-specific default, the comment and the manual both need to say that and say why.)
Some constructors have bugs when you try to turn off their sounds manually:
DirectSlider – no documented options to set sounds, but it does have sounds (via its Thumb button). A recent forum post reported the same issue:
File “dstroot/pythoncode/Developer/Panda3D/lib/direct/gui/DirectOptionMenu.py”, line 61, in init
TypeError: PGItem.setSound() argument 2 must be AudioSound, not NoneType
Design opinions:
all gui sounds should be None (absent) by default.
if that’s not done:
better default sounds should be chosen;
there needs to be an easy and well-documented way to turn off all gui sounds globally;
each gui widget manual page needs to list all sound options that affect it (even those it “inherits” from components, like the slider thumb);
there ought to be a uniform single option, supported on all DirectGui
widget constructors (regardless of their normal complete set of sound
options), to turn off all sounds for them.
(BTW, I’ve seen rumors that direct support for CEGUI is planned,
but I haven’t seen any recent status info on that.)
These are all good points. It should be easy to adjust the manual to add references to the missing options, and to adjust the DirectGui code to make the defaults be silence. Would you like to volunteer to do this work?
Sure, if I can get editorial guidance as needed (and if there is no deadline). For example, I don’t know whether the indirect options (like thumb_clickSound) are ever documented specifically, or where the general ability to pass them is documented, or where in the code is the most global place I could turn off the default sound options.
The manual is a wiki, as discussed in this thread.
We try to structure the manual as a guidebook, so that it introduces high-level concepts first, then gradually builds to show the way these things are used. The DirectGui pages aren’t as good at following this plan as some of the other pages in the manual, so it wouldn’t be a bad thing at all if someone were to restructure them to at least add a place to put the overall usability information, things like “you can configure nested pieces using piecename_component = componentValue, for instance thumb_clickSound = soundFile”.
As to where this should be tweaked in the code itself, I invite you to read the code. The DirectGui code is all Python (except where it falls back to the low-level PGui implementation), and though it’s not the easiest Python code in the world to read, it’s at least internally self-consistent. You’ll see that the clickSound and rolloverSound options appear in DirectButton.py, and ‘thumb’ is a DirectButton component of DirectSlider. You’ll also see that the default sounds are read from DGG.getDefaultClickSound(), and if you follow that to its source in DirectGuiGlobals.py, you’ll see that it can also be changed globally with DGG.setDefaultClickSound().
Whether this is a good interface is subject to some debate, of course; but it would certainly be easy to change the default to silent by editing the appropriate lines in DirectGuiGlobals.py.
Thanks for the pointer. I tried this change (for both sound globals):
def getDefaultClickSound():
## global defaultClickSound
## if defaultClickSound == None:
## defaultClickSound = base.loadSfx("audio/sfx/GUI_click.wav")
return defaultClickSound
But it led to the same error (I presume in the C++ code) as I reported in my original post from the explicit passing of None as a sound option to DirectOptionMenu; now it happens just from constructing a DirectOptionMenu without any sound options:
File "dstroot/pythoncode/Developer/Panda3D/lib/direct/gui/DirectOptionMenu.py", line 61, in __init__
TypeError: PGItem.setSound() argument 2 must be AudioSound, not NoneType
This is coming from the lines
# Make popup marker have the same click sound
self.popupMarker.guiItem.setSound(
DGG.B1PRESS + self.popupMarker.guiId, self['clickSound'])
I could change those lines to not run if self[‘clickSound’] was None, but that might not be a complete fix (I don’t know whether self.popupMarker.guiItem can have a preexisting click sound), and maybe the same issue exists for other widgets, so a better fix would be to make sure guiItem.setSound accepts None and clears the sound in that case. As I am not (yet) a C++ programmer, someone else would need to make that change.
(Or if you want to assure me that fixing just these places in the python code would be sufficient, I’ll need to find out how to commit changes to that code.)
Even if that’s resolved:
can we assume this change won’t cause other problems on some platform and for some sound library?
does the discussion we’ve just had constitute sufficient consensus to make this incompatible change to the code?
(Is there a better place to be discussing proposed changes to the code?)
I’d like to get the code settled before editing the manual, since how to edit it depends on what happens to the code. I also have some further editorial questions about the manual (after reading the editing guidelines), but I might as well ask them after I know what to write. Where is the best place to ask them at that time?
which means I know how to fix this entirely in Python (by similarly changing all calls of setSound). So if the overall change is desirable, but fixing setSound in C++ to accept None is for some reason not desirable, it could be done entirely in Python.
In general, the C++ methods cannot accept None, so the correct thing to do is to make a correction to the Python code that calls PGItem.setSound(), so as not to call it at all if that value is None, but to call PGItem.clearSound() instead. The fact that DirectOptionMenu doesn’t do this is really a bug in that file; you can see, for instance, that DirectButton does correctly handle this case.
For now, when you are ready to make the commit, please send the appropriate diffs (as generated via e.g. cvs diff -U) to either myself or rdb, and we’ll integrate them and commit them. If you are interested in becoming a regular contributor to the Panda source code, we’ll be more than happy to give you direct commit access to avoid this unwieldy step in the future.
In this case, I think that’s a safe assumption.
I’m satisfied. It’s not terribly incompatible, it just changes the default sound effect. To be most friendly, though, I suppose it might be nice to have a config setting to restore the original default sound effects. You could perhaps solve this with code like this somewhere in ShowBase.py:
if ConfigVariableBool('orig-gui-sounds', False).getValue():
DGG.setDefaultClickSound(self.loadSfx(...))
DGG.setDefaultRolloverSound(self.loadSfx(...))
and so on.
To pick nits, perhaps the “Compiling or Editing the Panda Source” forum would be a better choice. But in general, we use the forums for this purpose.
If I can trust my search of all the python code that was installed under /Developer/Panda as being definitive, then DirectOptionMenu is the only place that has this bug.
I’ll do that, thanks. I’ll put in the ConfigVariableBool you suggested first, unless I run into problems doing so.
I might as well get a head start on my next manual editorial question: in this case it would seem desirable to mention that this feature changed in 1.8.0, but I haven’t yet seen an example of that sort of statement in the manual. (Whereas it’s common in the Python manual, for example – it often says in which language version some feature was introduced or changed in a major way, and this is quite useful.) Is there a precedent to follow for this? (If not, I’ll just mention it in some sensible way, along with explaining how to get the old behavior if desired.)
There are a few examples throughout the manual of mentioning a particular Panda3D version. It’s not as formalized as the Python manual, though. For instance, I recently added this page, and there are similar references on pages like this and this.
drwr, I sent you a PM containing a patch earlier today. Let me know if you need it sent some other way (or posted here – it’s small), or if I should also send it to rdb.
