This in interesting, and needs to be proposed as part of an FD.o
discussion on protocol extensions.
I would also mention that the 'alt_text' hint is informational and
should not be rendered to the screen. It should only be transmitted to
applications requesting it through an accessibility framework.
Accessibility helper applications are then free to render the 'alt_text'
property in the appropriate manner.
** Changed in: notify-osd
Importance: Undecided => Wishlist
Status: Invalid => Confirmed
--
An "alt_text" hint should be introduced
https://bugs.launchpad.net/bugs/334272
You received this bug notification because you are a member of Notify
OSD Developers, which is subscribed to Notify OSD.
Status in Canonical's Notification Display Agent: Confirmed
Bug description:
notify-osd introduces icon-only notifications. Since no text is supplied, there
is no way of determining the non-visual meaning of these icons.
Often, it could be derived from the "synchronous" hint (like in brightness and
volume), but the text supplied by "synchronous" could be arbitrary, and there
is no guarantee that the icon-only notification will supply the "synchronous"
hint at all.
Potentially, the alternative text could be determined from the supplied icon
file name (assuming the file name has real meaning). But this is not always the
case since direct pixbufs could be sent to notify-osd with no associated file
name. In any case, the Bubble class does not currently store the file name
after the icon is rendered to a pixbuf.
Besides being hackish, and error prone, the two methods above do not provide a
means of localization for the utilizing applications.
That is why I propose the "alt_text" hint. For example:
notify-send " " -i notification-audio-volume-medium -h int:value:75 -h
string:synchronous:volume -h string:alt_text:Volume
_______________________________________________
Mailing list: https://launchpad.net/~dx-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~dx-team
More help : https://help.launchpad.net/ListHelp
