Some general issues with Phonon...

[Tanguy Krotoff]

>  Sorry that this doesn't always happen. :-(

Volunteers don't have so much time, i understand, I'm one of them...

>  The upside of using KDE svn is more exposure == more testers, more feedback,
>  more eyeballs on the code and perhaps some helping hands.

Of course, I know that, but for the future :)
Sometimes it feels good to code on your own as an authist. And then
when you feel it, "spread the world with your blessed software" :)

>  Just to keep in mind: There's no replace possible anymore since 4.0 (only with
>  the next major version, which nobody is planning on yet). Otherwise we'd
>  break compatibility.

Is it possible to add new methods, keep the others and mark them
deprecated (and of course keep them warm during KDE x.x life)?
It's always good for API users to have a symmetric API. If the Phonon
user knows how to deal with subtitles, he will know how to use
angles/chapters/audioChannels without even reading documentation and
without getting confused. Example:

connect(m_mediaController, SIGNAL(availableXXXsChanged()),
SLOT(availableXXXsChanged()));

void availableXXXsChanged() {
  list = m_mediaController->availableXXXs();

  foreach (item, list) {
  }

  m_mediaController->setCurrentXXX(item);
  item = m_mediaController->currentXXX();
}

Replace XXX with some horny stuffs like AudioChannel, Subtitle, Angle, Title...
If "item" is an int or a ObjectDescription, if "list" is a
QList<ObjectDescription> or an int, it doesn't really matter I think
This way you have a symmetric API. It should even be possible to ugly
macrotize this.

>  Would be nice if it were possible without #ifdefs. Most of the test code in
>  phonon should be kdelibs independent. Except perhaps for bit of helper code
>  that could be copied from qtest_kde.h

Then I send you a patch to make everything totally kdelibs independent...
Just a few ifdef where Phonon needs to deal with KDE integration.
(Why not even be extremist and switch to qmake/.pro? Trolltech will be
happy with that, personally I definitly prefer CMake and I urge the
trolls to switch)

The only problem I currently see is the #include "moc_blabla.cpp", as
the original stupid FindQt4.cmake names them "moc_blabla.cxx"...
By the way, without KDE CMake macros, Phonon might compile faster as
there is no need to include_directories() all Qt includes.
Smaller include path, faster compilation time...
Do you think #include "moc_blabla.cpp" really increase compilation
times? I never use this...

A Phonon CMakeLists.txt independent from KDE would look like:

find_package(KDE4)
if (KDE4_FOUND)
	include(KDE4Defaults)
	include(MacroLibrary)

	add_definitions(-DHAVE_KDE4_MULTIMEDIA)

	add_definitions(${QT_DEFINITIONS} ${QT_QTDBUS_DEFINITIONS} ${KDE4_DEFINITIONS})
	include_directories(${QDBUS_INCLUDE_DIRS} ${CMAKE_SOURCE_DIR}
${CMAKE_BINARY_DIR} ${KDE4_INCLUDES})

	message(STATUS "KDE4 support enabled")
else (KDE4_FOUND)
	find_package(Qt4 REQUIRED)

	#Qt include dir
	include_directories(${QT_INCLUDE_DIR})

	message(STATUS "KDE4 support disabled")
endif (KDE4_FOUND)


>  > I think Phonon should be a Qt based library more than a KDE library.

I mean Phonon and its CMakelists.txt/tests brothers...

>  It already is. But in addition to that it integrates into KDE automatically
>  without the application having to link against KDE.

>  > Have you ever though about totally removing Phonon from kdelibs?
>
>  Yes, and I'm seriously considering it. We will need at least one more release
>  with kdelibs in order to make the Trolltech backends first-class citizens in
>  KDE. After that phonon perhaps will move out of kdelibs and release
>  independently.

COOL !!! I offer you 10 beers for that (next FOSDEM?) huhu

-- 
Tanguy Krotoff <tkrotoff at gmail.com>
+33 6 68 42 70 24