Sound naming spec: problems with prefixes

[Bastien Nocera]

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
> too. 
> 
> 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
design decision.

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

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
> windows?

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:
> 
> audio-*
> completion-*
> count-down
> camera-*
> screen-capture-*
> phone-*
> device-*
> software-update-available
> software-update-urgent
> system-*
> 
> Merge:
> 
> all with "trash"
> desktop-switch-*
> message-new-*
> bell-*
> window-attention-*
> window-inactive-click-*
> message-sent-*
> 
> 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
> sounds:
> 
>    dialog-error
>    dialog-warning
>    dialog-information
>    dialog-question
>    window-new
>    window-close
>    window-minimized
>    window-unminimized
>    window-maximized
>    window-unmaximized
>    notebook-tab-changed
>    dialog-ok
>    dialog-cancel
>    item-selected
>    link-pressed
>    link-released
>    button-pressed
>    button-released
>    menu-click
>    button-toggle-on
>    button-toggle-off
>    menu-popup
>    menu-popdown
>    menu-replace
>    tooltip-popup
>    tooltip-popdown
> 
> 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.