Re: State of Audio CD support in KDE

2015-09-29 Thread Albert Astals Cid 
El Dimarts, 29 de setembre de 2015, a les 04:05:36, Boudhayan Gupta va escriure:
> Hi all,
> 
> In porting libKCompactDisc from kdelibs4 to kf5 I've discovered that
> libKCompactDisc doesn't actually work, in that it can neither detect
> an audio CD in the drive nor play it.
> 
> Further, looking at the code of other KDE projects I've discovered no
> one actually uses libKCompactDisc to play audio CDs. We have:
> 
> *audiocd-kio, which uses the library to get the number of tracks in the
> disc. *audex, which just crashes (it uses the library to get a list of CD
> drives, apparently).
> *kaudiocreator depends on it, but lxr doesn't show any usage of
> "KCompactDisc" in it.

 ./kaudiocreator.kcfg:21:  KCompactDisc::defaultCdromDeviceName()

seems to be the only use i can find.

> *kscd doesn't use it anymore.
> 
> In all, KCompactDisc hasn't probably worked for years and no one's
> noticed because no one's been using it.
> 
> In terms of support for Audio CDs in KDE,
> 
> * K3B can write them.
> * Phonon the API can play them, with some minor but weird bugs.
> 
> And that's it.

Does solid offer some support?
I guess at least it can say how many drives are there
but maybe nothing related to Audio-CD itself?

> 
> I think we need to take a long hard look at the state of support for
> Red Book CDs in KDE and decide:
> 
> a) Do we still want to support them, and
> b) If yes, to what degree do we support them?

I'd say we totally want to support them. The question is if there's
something that can be shared in an library or should it be app specific.

The things i can think of doing with an Audio-CD are:

 * ripping it
 * playing it
 * copying it to another Audio-CD

Ripping and playing have some "common" stuff that is:
 * Finding the CD drive that actually has a Audio-CD inside (if you have 
muliple drivers and others
   are either empty or have data CDs)
 * Listing the number of tracks and their info (cddb, or whatever)
 * Extracting data to either feed it to the player or ripper

So I think that having a library that those these 3 basic things is a good 
thing, once we have it we
can see how to make it used in kio-audiocd, kaudiocreator, kscd or whatever cd 
apps we decide to have.

I can't think of a "common" stuff between copying and and ripping/playing.

Anyone else?

Cheers,
  Albert

> 
> Based on that, I'll decide whether and how to kill/repurpose/fix
> KCompactDisc and other apps which work with it.
> 
> Cheers,
> Boudhayan Gupta

Re: State of Audio CD support in KDE

2015-09-29 Thread Boudhayan Gupta 
Hi Albert (and others),

On 30 September 2015 at 04:09, Albert Astals Cid  wrote:
>> In terms of support for Audio CDs in KDE,
>>
>> * K3B can write them.
>> * Phonon the API can play them, with some minor but weird bugs.
>>
>> And that's it.
>
> Does solid offer some support?
> I guess at least it can say how many drives are there
> but maybe nothing related to Audio-CD itself?

Solid is interesting. It can detect the number of drives in the
system, and it can tell us if the CD inside is an Audio CD.

We can also subscribe to signals from Solid that notify is the disc is
ejected, but there's no signal in Solid::OpticalDrive to notify if a
new disc was inserted. Maybe it's a small patch that can be worked on?

>> I think we need to take a long hard look at the state of support for
>> Red Book CDs in KDE and decide:
>>
>> a) Do we still want to support them, and
>> b) If yes, to what degree do we support them?
>
> I'd say we totally want to support them. The question is if there's
> something that can be shared in an library or should it be app specific.
>
> The things i can think of doing with an Audio-CD are:
>
>  * ripping it
>  * playing it
>  * copying it to another Audio-CD
>
> Ripping and playing have some "common" stuff that is:
>  * Finding the CD drive that actually has a Audio-CD inside (if you have 
> muliple drivers and others
>are either empty or have data CDs)
>  * Listing the number of tracks and their info (cddb, or whatever)
>  * Extracting data to either feed it to the player or ripper
>
> So I think that having a library that those these 3 basic things is a good 
> thing, once we have it we
> can see how to make it used in kio-audiocd, kaudiocreator, kscd or whatever 
> cd apps we decide to have.
>
> I can't think of a "common" stuff between copying and and ripping/playing.

So here's the situation:

Ripping and playing have some commonality in them, in that they both
need access to raw PCM data from the disc. Phonon seems to have pretty
good playback support (I'll file bug reports for the bugs I've been
mentioning) - so if you have an app that uses Phonon you've got
support for playing back CDs. Let's not reinvent that wheel, but round
it out if there are flat spots.

Now information and ripping. KCDDB seems to be in pretty good shape
(kdelibs4 though) - for getting data about the CD from CDDB servers.
Whatever work I've done for the libKCompactDisc nextgen branch, I can
extract raw PCM data from the disc and also read CD-TEXT information
to find whatever data is embedded in the disc.

kaudiocreator seems to be using CDParanoia directly, as is
audiocd-kio. I tried to start a basic port of audiocd-kio to kf5
today, but audiocd-kio is also trying to do too much, because I've
been looking through the code and it has converters for MP3, FLAC and
OGG in it.

What I would suggest is:

1: Let Phonon do the playing
2: Let k3b do the copying
3: Let Solid do all the disc detection
4: Consolidate libKCDDB and libKCompactDisc into an all-in-one
disc-info and raw-data-from-CD library
5: Write a new, very small cdda kioslave that just exposes the audio
files on the CD as a set of wav files. We can re-use code from the
current audiocd-kio.
6: Once the new lib is up, port KAudioCreator to kf5.

This plan of action will eventually end up removing a lot of lines of
code and reducing our maintenance burden. Right now:

* kaudiocreator and audiocd-kio both duplicate media conversion code.
* both use cdparanoia, and do the same thing differently
* all of them have their own disc detection code

Inputs?

Cheers,
Boudhayan Gupta

Review Request 125452: This is a patch for KImgIO that handles xcfgz / xcfbz2 (compressed GIMP) images in KDE (read-only).

2015-09-29 Thread Tudor PRISTAVU 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125452/
---

Review request for kdelibs.


Bugs: 126072
http://bugs.kde.org/show_bug.cgi?id=126072


Repository: kdelibs


Description
---

Add support for GIMP's compressed xcf files (xcfgz / xcfbz2).


Diffs
-

  kimgio/CMakeLists.txt bffe44ffb2802c80e9106ab96358ecdab9193c29 
  kimgio/xcf_compressed.cpp PRE-CREATION 
  kimgio/xcf_compressed.desktop PRE-CREATION 
  kimgio/xcf_compressed.h PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/125452/diff/


Testing
---


Thanks,

Tudor PRISTAVU

Re: Review Request 125452: This is a patch for KImgIO that handles xcfgz / xcfbz2 (compressed GIMP) images in KDE (read-only).

2015-09-29 Thread Martin Klapetek 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125452/#review86126
---


Thanks for your patch!

Unforunately kdelibs is closed for new features and is in maintenance mode 
only. You'd need to port your code to Qt5 and include it in KImageFormats 
framework to get it released.

- Martin Klapetek


On Sept. 29, 2015, 7:56 p.m., Tudor PRISTAVU wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125452/
> ---
> 
> (Updated Sept. 29, 2015, 7:56 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Bugs: 126072
> http://bugs.kde.org/show_bug.cgi?id=126072
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Add support for GIMP's compressed xcf files (xcfgz / xcfbz2).
> 
> 
> Diffs
> -
> 
>   kimgio/CMakeLists.txt bffe44ffb2802c80e9106ab96358ecdab9193c29 
>   kimgio/xcf_compressed.cpp PRE-CREATION 
>   kimgio/xcf_compressed.desktop PRE-CREATION 
>   kimgio/xcf_compressed.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125452/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tudor PRISTAVU
> 
>