Sound naming spec: problems with prefixes
hadess at hadess.net
Thu Jul 17 07:57:48 PDT 2008
On Thu, 2008-07-17 at 16:32 +0200, Lennart Poettering wrote:
> On Thu, 17.07.08 14:29, Bastien Nocera (hadess at hadess.net) wrote:
> > Heya,
> > I feel some of the names for the sounds are the wrong way around.
> > For example:
> > network-connectivity-lost
> > network-connectivity-error
> > network-connectivity-established
> > To me, network-connectivity-error should be error-network-connectivity.
> > So that we could have a generic error sound.
> But having a generic sound to alert the user about network
> connectivity changes might make sense too?
> I think people can always see this both ways. When Marc-Andre and I
> discussed this we came to the conclusion that we have to pick *one*
> order, regardless if there might be a use case for the opposite order
> Maybe to fix this properly we should allow both prefixing and
> postfixing sounds? i.e. when we look for a sound "a-b-c" we should
> look for the power set of it i.e. for "a-b-c", "a-b", "b-c", "a", "b",
> "c". This would be a significant departure from the icon naming logic
> however. Sounds like overkill on first sight, but actually I don't
> think it would be that bad. Or maybe instead of the power set we pick
> the set of all prefixes in union with all suffixes? i.e. "a-b-c",
> "a-b", "b-c", "a", "c" -- but no "b".
I don't think we need to implement something as complicated as that.
Let's leave it as-is, but add a little blurb in the spec mentioning the
> > The problem I see is that for some sounds, it's good to be able to match
> > to a prefix, but sometimes it's not good enough. So to set a generic
> > "error" sound, I'd need to modify:
> > dialog-error
> For dialog-error some people might prefer to have a single sound for
> all dialogs popping up, instead of having a single sound for all
> errors that happen. Hence again, the order of these names is very much
I can see both happening, but errors are always something a bit special,
compared to dialogues popping up.
> > I've targetted 30-odd sounds (including the bell) to be user modifiable
> > in the preferences:
> > * Battery warning:
> > power-unplug-battery-low
> > battery-low
> > battery-caution
> > * Long action completed:
> > complete-copy
> > complete-download
> > complete-media-burn
> > complete-media-rip
> > complete-scan
> > * Bells:
> > bell-terminal
> > bell-window-system
> > * Button clicked:
> > button-pressed
> > menu-click
> > menu-popup
> > menu-popdown
> What do you want to do with menu-replace?
I should add it to the above as well.
> > * Button toggled:
> > button-toggle-off
> > button-toggle-on
> > * Login:
> > desktop-login
> > * Logout:
> > desktop-logout
> > * Error:
> > dialog-error
> > * Information or question (have a better idea?)
> > dialog-information
> > dialog-question
> Hmm, sounds for opening dialogs but no sounds for opening/closing
It's not "opening" dialogues (as in, I click on preferences, and it
opens a new window), but questions or warnings that should be brought to
the user's attention.
> > * Warning:
> > dialog-warning
> > * New email:
> > message-new-email
> No IM sounds? Maybe collapse IM and email to "message-new"?
This is only the list of sounds that I'd like users to be able to
override. The default IM sounds will probably be fine.
> > * Empty trash:
> > trash-empty
> > * Window maximised:
> > window-maximized
> > * Window unmaximised:
> > window-unmaximized
> > * Window minimised:
> > window-minimized
> No window-unminimized?
We don't currently have one, and the visible feedback seemed adequate to
me. If you feel strongly about it, I'll add it.
> > What do you think?
> Dunno. I'd properly start the otherway round: i.e. take the full list
> and remove the items I think are unnecessary to show or can be
> merged into a single prefix. So, take the full list and subtract:
> all with "trash"
> I am not sure to what this boils down however, and where it differs
> from your list.
It's pretty much what I did offline...
> Then, I'd probably have in the code but commented all sounds that we
> do not generate any sound for at the moment. Since libcanberra-gtk-module is the
> only code that currently generates sounds this would leave these
> OTOH: all of these are input feedback sounds. We have a checkbox for
> that anyway. Maybe these are the ones which should not be displayed at all?
It's not only about disabling the sounds, it's also reassigning them. So
we'd only have a limited list of sounds in there, and changing the
default for say "Button clicked" would override 5 sounds.
More information about the xdg