Phonon Sample Cache

[Trever Fischer]

On Saturday, August 27, 2011 09:00:37 PM Ian Wadham wrote:
> Hi Colin, and thanks for taking some notice of what I had to say ... :-)
> 
> On 27/08/2011, at 10:28 PM, Colin Guthrie wrote:
> > 'Twas brillig, and Ian Wadham at 27/08/11 00:54 did gyre and gimble:
> >> KGoldrunner sounds are already themed and have been for more than
> >> three years.  It is no sweat.  The sounds just go in the same directory
> >> structure as the graphics themes.  It is true, however, that while there
> >> are six graphics themes, there is only one sound theme.  I think that
> >> is just because sound composers are even harder to find than graphics
> >> artists.
> > 
> > This is great, but I'd be interested in making things work in a standard
> > way rather than an ad-hoc, per-application basis. I appreciate this may
> > mean some changes to where you install the sounds, but I don't think
> > it's a massive upheaval and I think the sound-theme specification is
> > something that can benefit everyone on the systems generally. That said,
> > I fully appreciate if you are reticent to this kind of change.
> 
> Well, the way we manage graphics themes in KDE Games *is* standardised
> and has been since at least a year before the first release of KDE 4.  This
> standardisation is supported by conventions artists can follow in their SVG
> files and KDE translators can use when translating the names and
> descriptions of themes.  It is also supported by modules in the KDE Games
> Library that find themes, display them in dialogs, render graphics and
> manage caches of pixmaps.  I do not think the KDE Games team are
> about to change all that across dozens of games.
Is there documentation in one of the *base wikis for this stuff?
> 
> Adding sounds to the graphics structure was not so much "ad hoc" as
> a logical extension to what was already there IMO.  Another author wrote
> that code, but I am not likely to change it.
Any idea where to start looking for that code?
> 
> I am not against standards.  Indeed I have always promoted them
> throughout a long career as a programmer, designer and project
> manager.  It's just that you need to get them in place *before*
> people have written much code.  It is unrealistic, unproductive and
> actually risky IMO to expect people to rewrite code that is currently
> working well just because a new standard has been introduced,
> unless of course the standard has the force of law.  I wonder when
> the USA will go metric ... :-)
I've been wondering that myself. Everyone looks at me funny when I don't tell 
them the temperature in fahrenheit.

Back on topic here, I'm not entirely sure if we should do any kind of theming 
at all. I've been thinking a bit about the problem today, and it might just be 
in everyone's best interest for the sample cache to simply play files and not 
handle any theming or anything. Using libcanberra to handle this in libphonon 
(instead of the backends themselves) would simply be a convienence for us 
since all the low latency bits are already handled.

If a pure Qt application needs to use the sound theme, they can use 
libcanberra directly. If a KDE application needs to use the sound theme, they 
can use kdelibs to find the right file and pass it to phonon, which would allow 
it to work on all platforms.

The way I see it, a kdelibs application will already have the 
/usr/share/sounds/ filesystem and such in place on non-linux platforms. They'll 
have the sound theme "in place" so to speak.

A boring, proprietary Qt application (and some FOSS ones) won't have any 
concept of the XDG specs simply because they want to work on all platforms. 
For those applications, they'll be in control of the files that get installed 
into which location. For those applications, it would be in their best 
interest to either use kdelibs to get a properly implemented theme resolution 
algorithm or to figure out how to write their own if it really matters to them.

A simple C library that resolves themes that everyone can share probably isn't 
that bad an idea.
> 
> Cheers, Ian W.
> _______________________________________________
> kde-multimedia mailing list
> kde-multimedia at kde.org
> https://mail.kde.org/mailman/listinfo/kde-multimedia