From: Jorg S. <Jor...@gm...> - 2007-04-27 11:06:15
|
So let me try to make my own summary: - the fdi files are useful and need to be included somehwere - just as Christophe said: what good does it do for any application to know that they can read the iTunesDB with libgpod. Paul: even if amarok determines that it can handle an iPod with libgpod, it will NOT load up libgpod put simply a plugin that handles iPods. That plugin may or may not use libgpod. - so that leads me to believe that there is some confusion about how iPods are accessed. All iPods are accessed as removable harddisks. No additional library is needed to access an iPod. Or at least libgpod is not needed to access an iPod. No application will learn anything from an entry saying "libgpod handles iPods" as far as I can see. More interesing would be an entry "access method = gtkpod/amarok/whatever". That is unless I'm still missing an essential point. As for the future of libgpod: there may indeed be a need to marry libgpod with hal at some point, but simply in order to get the XML file from the iPod that describes the supported music and video formats, as well as the artwork formats, which are currently completely hardcoded. How I see it, however, the application will continue to contact libgpod with a valid mountpoint (or directory for "test-iPods"), and not the other way around. > On side note ... > - Definitely would like auto mount point detection. Me too -- I agree with Christophe that this should be done by the application through hal. > - Also like the idea of repositories appearing and disappearing in gtkpod > depending on what is connected. Does anyonelse like this as an idea? Me. But only in addition to static iPod repository that stay put ("can't use gtkpod because hal does not recognize my mounted iPod that I can access without problems from a shell" isn't something I want to have to deal with ;-) ) Cheers, JCS. |