GNOME Bugzilla – Bug 325895
Install libjuicer for other apps
Last modified: 2021-05-17 15:55:26 UTC
If the ripping code and some utility logic/UI were a library, then other applications could re-use it trivially.
Created attachment 57037 [details] [review] start of a patch This is the start of a patch to do this, based on totem-plparser's autofoo. It exports the metadata lookup stuff as a shared library and headers. With a trivial patch, Rhythmbox can be built against this instead of the copied code. Obviously there is still be a lot of work to do: add the ripping code, make the library only export symbols it should, not have sj-util/sj-error/sj-structure code be in both the library and SJ, etc.
Sweet. I'd like to see the library in a separate directory too, but this is a step in the right direction. If I get the time I'll start by making libjuicer noinst as well so we can migrate code over time.
Created attachment 59812 [details] [review] updated patch Patch updated with a few minor fixes, and also exports the stuff in sj-extractor. It may be too late, but it would be really nice if this could get in before 2.14. - that way people who build RB wouldn't need to have SJ 2.15.x. I'm fairly sure that this wouldn't cause any new bugs, but I'm not sure how (or if) API-freeze affects desktop modules.
That patch only contains the Rhythmbox changes...
I've just noticed that you've committed the split-into-libjuicer in cvs. I'm planning to make RB use the system-installed copy if present; is it safe to assume you haven't got any huge "break the api every few days" plang?
At the moment it's a noinst library, as I do plan on doing something interesting to the metadata API. However I'm not sure yet... if I don't have any cunning plans I'll just install it.
Ping? Any chance that libjuicer could be exported so that rhythmbox would pick it up?
I'm currently rewriting it to be saner, and plan on installing it in G2.20. I'll shortly export a bzr tree of my rewrite so people can have a prod. One important question: is a libnautilusburn dependency too weird for the library? Currently the rewrite uses a NautilusBurnDrive* as the drive to read from rather than a simple char * device path.
Rhythmbox currently requires libnautilusburn for audio cds support anyway, so it won't affect us. I don't know if it would be too much for anything else that may want to use libjuicer.
Gentoo users will complain that they have to build the whole nautilus stack to get libnautilusburn, but they'll also complain that they have to build sound-juicer to get libjuicer. I'm not saying that you should care, this is just a head up about what will happen ;)
For RB could keep our in-tree copy of S-J's code (but updated obviously) and use it as a backup if there is no system-installed one. Like we current do with sexyiconentry (libsexy).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/sound-juicer/-/issues/43.