The actual version of the dfiso-plugin depends on nautilus, the file manager from gnome. I had a look at the code and the sole purpose for such a dependance seems to be the choise of the correct cd-rom device. In earlier versions this was solved by an input field which contained a default-device (/dev/cdrom) and which one could overwrite. If there is no other reason for the dependancy I would like to turn back to the old mechanism because possibly not everyone uses nautilus (like me ;-)).
Btw. is someone actually working on this plugin or a conversion of the old cdrmooby to gtk2 ? dfiso lacks of cdda-playback atm ...
And a last question important for the debanists: Did someone manage to contact the original author of cdriso (guess his name was linuzappz or something) to get a correct opensource licencse ?
Stefan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
True - the CD ROM device selection was based on Sound Juicer if I recall. My CD actually rips only using the /dev/scd0 device, which is pretty obscure from what I would have expected to be the case (/dev/cdrom).
Since I wanted to make it easy for beginners to use it, I wanted something that would mean they would not need to know the device name, and the Nautilus CD Burner library seemed to be the best fit. Know any other libraries/C code that may help? In any case, it's only the Nautilus CD library, not the whole kitchen sink ;)
Converting cdrmooby to GTK2 isn't on my radar - plus it's written in C++ which I don't really want to tackle. And considering the dfiso and dfcdrom plugins do most of what dfbinimage does (but maybe not CDDA) then I don't think it's a major priority.
As to the licensing question, I'm not 100% sure, but Ryan may know since he did the original work to get it into the Debian repository in the first place.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll have a look at the auto-detection from xcdroast, perhaps we can borrow some code there.
dfiso lacks of of cdda and dfbinimage (cdrmooby) uses fltk... So we have a choice.
1) Converting cdrmooby to gtk2 or
2) integrate the missing functions in dfiso and put together dfiso and dfcdrom.
I am quite indifferent.
Since cdrmooby is GPL the licensing question of dfiso could be obsolete if we choose version 1.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
xcdroast uses "cdrecord -scanbus" for determining the cdrom-devices.
But what do you think about a C-version of the following ?:
--------------- snip --------------------
#!/bin/bash
for device in `ls /sys/block`
do
if test -e /sys/block/$device/device/media; then
if test $(cat /sys/block/$device/device/media) = "cdrom"; then echo $device is CDROM; fi
fi
done
echo "Scan complete";
-------------- snap --------------------
At least it worked for me (/dev/hda is my dvd-burner) and this way we could offer the devices without using a bloated library.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That bash script didn't work for me - my cdrom is at /dev/scd0, which doesn't have a corresponding media file in the device dir. I'll see what I can get out of cdrecord.
I'm leaning towards having a compile option to enable the nautilus library, the only question is around which default to use ;) I'd like to enable it by default, since it would then look the same as most other GTK apps which use CD (e.g. Nautilus, SoundJuicer, etc).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also, hdhoshy, the current CVS code reverting to a combo box with only /dev/cdrom available doesn't work for me - dfiso will not rip the CD at that location.
I want to put the Nautilus code back in as a ./configure option, and retain your code as the alternate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Andrew,
another alternative would be to add more default drives to the combo-box. /dev/cdrom is set in case the code for /sys does not find a media descriptor. This can be done easily in get_drivelist().
If you put back the nautilus code it would be great when the configure script looks for the nutilus-lib and sets a variable so my code is used as fallback for people without nautilus (like me ;-) ).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you check out latest version from CVS and test? You'll need to add the configure flag --enable-nautilusburn=no to use your code (i.e. without the nautilus libs).
I preferred not to add a list of default drives to choose from since I wanted to make it nice and easy so that even n00bs could work out which drive to use ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes I tested your version. Works great and I saw that you integrated dfOpenGL into the autobuild-process, too. Meanwhile I added some bugfixes for the memory functions and CdLoad-Functions.
Btw. it would be nice if everyone keeps track of his changes in the ChangeLog. I try to add the things I see but when the project gets more busy it will be more difficult to catch every change ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I started to develop some code for the cdiso-plugin to play back CDDA from raw images. What I have so far is a stable multithreaded program that plays music from a raw image with a given offset and length. I commit the code as soon as possible. Btw. I am using ALSA for this but the code is very modular so other audio-systems can be attached easily.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Today I commited the additional code. I guess there may be still errors, so please give the dfiso a try.
I also tried to contact LinuzAppz to get a clean GPL for the old cdriso-plugin, but he seems to be disappeared from the net. So I think I will rewrite the plugin to have a proper license. Since I don't use compressed file images I'd like to drop this feature from the code. Same for the iso-creator because cdrdao does the job.
What do you think ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The actual version of the dfiso-plugin depends on nautilus, the file manager from gnome. I had a look at the code and the sole purpose for such a dependance seems to be the choise of the correct cd-rom device. In earlier versions this was solved by an input field which contained a default-device (/dev/cdrom) and which one could overwrite. If there is no other reason for the dependancy I would like to turn back to the old mechanism because possibly not everyone uses nautilus (like me ;-)).
Btw. is someone actually working on this plugin or a conversion of the old cdrmooby to gtk2 ? dfiso lacks of cdda-playback atm ...
And a last question important for the debanists: Did someone manage to contact the original author of cdriso (guess his name was linuzappz or something) to get a correct opensource licencse ?
Stefan
True - the CD ROM device selection was based on Sound Juicer if I recall. My CD actually rips only using the /dev/scd0 device, which is pretty obscure from what I would have expected to be the case (/dev/cdrom).
Since I wanted to make it easy for beginners to use it, I wanted something that would mean they would not need to know the device name, and the Nautilus CD Burner library seemed to be the best fit. Know any other libraries/C code that may help? In any case, it's only the Nautilus CD library, not the whole kitchen sink ;)
Converting cdrmooby to GTK2 isn't on my radar - plus it's written in C++ which I don't really want to tackle. And considering the dfiso and dfcdrom plugins do most of what dfbinimage does (but maybe not CDDA) then I don't think it's a major priority.
As to the licensing question, I'm not 100% sure, but Ryan may know since he did the original work to get it into the Debian repository in the first place.
I'll have a look at the auto-detection from xcdroast, perhaps we can borrow some code there.
dfiso lacks of of cdda and dfbinimage (cdrmooby) uses fltk... So we have a choice.
1) Converting cdrmooby to gtk2 or
2) integrate the missing functions in dfiso and put together dfiso and dfcdrom.
I am quite indifferent.
Since cdrmooby is GPL the licensing question of dfiso could be obsolete if we choose version 1.
edit:
xcdroast uses "cdrecord -scanbus" for determining the cdrom-devices.
But what do you think about a C-version of the following ?:
--------------- snip --------------------
#!/bin/bash
for device in `ls /sys/block`
do
if test -e /sys/block/$device/device/media; then
if test $(cat /sys/block/$device/device/media) = "cdrom"; then echo $device is CDROM; fi
fi
done
echo "Scan complete";
-------------- snap --------------------
At least it worked for me (/dev/hda is my dvd-burner) and this way we could offer the devices without using a bloated library.
That bash script didn't work for me - my cdrom is at /dev/scd0, which doesn't have a corresponding media file in the device dir. I'll see what I can get out of cdrecord.
I'm leaning towards having a compile option to enable the nautilus library, the only question is around which default to use ;) I'd like to enable it by default, since it would then look the same as most other GTK apps which use CD (e.g. Nautilus, SoundJuicer, etc).
Also, hdhoshy, the current CVS code reverting to a combo box with only /dev/cdrom available doesn't work for me - dfiso will not rip the CD at that location.
I want to put the Nautilus code back in as a ./configure option, and retain your code as the alternate.
Hello Andrew,
another alternative would be to add more default drives to the combo-box. /dev/cdrom is set in case the code for /sys does not find a media descriptor. This can be done easily in get_drivelist().
If you put back the nautilus code it would be great when the configure script looks for the nutilus-lib and sets a variable so my code is used as fallback for people without nautilus (like me ;-) ).
Can you check out latest version from CVS and test? You'll need to add the configure flag --enable-nautilusburn=no to use your code (i.e. without the nautilus libs).
I preferred not to add a list of default drives to choose from since I wanted to make it nice and easy so that even n00bs could work out which drive to use ;)
Yes I tested your version. Works great and I saw that you integrated dfOpenGL into the autobuild-process, too. Meanwhile I added some bugfixes for the memory functions and CdLoad-Functions.
Btw. it would be nice if everyone keeps track of his changes in the ChangeLog. I try to add the things I see but when the project gets more busy it will be more difficult to catch every change ;-)
Apologies - will add ChangeLog entries in the future.
No problem, the project is just about to start.
Hello,
I started to develop some code for the cdiso-plugin to play back CDDA from raw images. What I have so far is a stable multithreaded program that plays music from a raw image with a given offset and length. I commit the code as soon as possible. Btw. I am using ALSA for this but the code is very modular so other audio-systems can be attached easily.
Today I commited the additional code. I guess there may be still errors, so please give the dfiso a try.
I also tried to contact LinuzAppz to get a clean GPL for the old cdriso-plugin, but he seems to be disappeared from the net. So I think I will rewrite the plugin to have a proper license. Since I don't use compressed file images I'd like to drop this feature from the code. Same for the iso-creator because cdrdao does the job.
What do you think ?
Hello Stefan,
I got the latest version on cvs today and the dfiso plugin does not compile anymore, make fails with :
make[1]: *** No rule to make target `alsaplay.lo', needed by `libDFIso.la'. Stop.
It seems that you forgot to commit some files on cvs.
Exactly :-( alsaplay.c and alsaplay.h were missing. Don't know how this could have happen :-D Of course I committed again.