Shared OSD Service for KDE

Colin Guthrie gmane at
Mon May 10 12:38:33 BST 2010

'Twas brillig, and Ozan Çağlayan at 10/05/10 12:08 did gyre and gimble:
> Another approach would be to provide methods like showBrightnessOSD, 
> showVolumeOSD which will decide the icon(audio-volume-muted, high, low, etc.) 
> based on the percentage. This is currently calculated in KMix.

I think it would be best to avoid being too specific. I think the client
side should be the bit that is contextually aware. While icon+slider
value is obviously correlated, I think it would be best to generic.

Here is a neat idea tho':

Perhaps the icon naming specification can be used to good effect here. I
don't know the right base name to use here but in theory if you supply
an icon name of:


Then the icon naming spec will automatically fall back to the less
specific names (e.g. it will try to find an icon with the full name
("sound-volume-90-95-97") then it will fall back to being less specific
("sound-volume-90-95", then "sound-volume-90", then "sound-volume" and
finally "sound"). That way you can supply 10 icons at the various levels
named sound-volume-90.svg sound-volume-80.svg etc. and not worry about
finer granularity. That way you just pass in the base icon name in your
call and the OSD widget knows to add on the suffix for the percentage.


icon = "sound-volume";
if (has_progress)
  icon += "-" + floor10(progress.value);
  icon += "-" + floor5(progress.value);
  icon += "-" + progress.value;

This way at the client side (e.g. kmix) you only supply a base icon, you
get the same one for whatever value the slider is. If you do provide
granular icons you've got three choices of icon granularity: every 10,
or every 5 or every 1.

This generic approach would work for all OSDs with progress bars.




Colin Guthrie

Day Job:
  Tribalogic Limited []
Open Source:
  Mandriva Linux Contributor []
  PulseAudio Hacker []
  Trac Hacker []

More information about the kde-core-devel mailing list