I was just wondering why xcdroast gets included as the standard cd writer and not gcombust. I always end up frustrated with xcdroast and gcombust is quite friendly. Also, it's obvious how to write an existing iso image with gcombust and I don't see that xcdroast can even do it. Plus gcombust fits in nicely with Bluecurve and is at least a GTK app, whereas xcdroast is, well, whatever it is. I there a licensing issue or something?
Then again, eventually, I suppose, nautilus will do it all.
Just curious.
-Steve
On Sun, Aug 31, 2003 at 03:25:01PM -0500, Steve Bergman wrote:
I was just wondering why xcdroast gets included as the standard cd writer and not gcombust. I always end up frustrated with xcdroast and gcombust is quite friendly. Also, it's obvious how to write an existing iso image with gcombust and I don't see that xcdroast can even do it.
Yes, xcdroast can do this very easily. Not very happy with then UI too, but I have that with every *G*UI ;-), so I don't know if it is that bad. Never looked at gcombust, I'm used to xcdroast and the command-line tools.
On Sun, 2003-08-31 at 16:25, Steve Bergman wrote:
I was just wondering why xcdroast gets included as the standard cd writer and not gcombust. I always end up frustrated with xcdroast and gcombust is quite friendly. Also, it's obvious how to write an existing iso image with gcombust and I don't see that xcdroast can even do it. Plus gcombust fits in nicely with Bluecurve and is at least a GTK app, whereas xcdroast is, well, whatever it is. I there a licensing issue or something?
Then again, eventually, I suppose, nautilus will do it all.
Let's hope not. Nautilus lacks the configurability you'd want out of a cdburning application.
K3b does a nice job on cdburning and has the options necessary for useful disk burning like *gasp* burning audio cds.
-sv
On Sun, 31 Aug 2003, Steve Bergman wrote:
I was just wondering why xcdroast gets included as the standard cd writer and not gcombust.
Why not $ONE_OF_A_THOUSAND other CD burner applications? Seriously, we can't ship every single application ever written in every application category. We can chip one or two apps for most important categories, but anything beyond that is distribution bloat, and should be in a separate repository such as fedora or another alternative repository, perhaps tied to the RHLP somehow.
By all means, file an RFE to have gcombust added to the distribution, that's the normal way things get added. There's no guarantee it will get added automatically of course, but at least it can be considered when we're investigating new packages next time around.
I always end up frustrated with xcdroast and gcombust is quite friendly.
The xcdroast UI is not perfect by any means, but I find it quite functional personally. I've been using it since it was a TCL/TK script.
Also, it's obvious how to write an existing iso image with gcombust and I don't see that xcdroast can even do it.
Well you're wrong there. 99% of what I use xcdroast for is doing just that.
Plus gcombust fits in nicely with Bluecurve and is at least a GTK app, whereas xcdroast is, well, whatever it is. I there a licensing issue or something?
Did you file a request in bugzilla? If not, file it against the "distribution" component. If you know the email addresses of any of the maintainers in the distribution of existing CD burning packages, you might want to carbon copy them as well. We investigate user suggested packages submitted to bugzilla every release. Some of them get accepted, some end up replacing an existing package in the distro, and some get rejected for one reason or another. It's best to have it in bugzilla however, so it can be tracked.
Then again, eventually, I suppose, nautilus will do it all.
Nautilus already can burn CDs.
Hope this helps.
I think that the answer to my question is that a lot of people like xcdroast better than I do. ;-)
I'll give it another try.
I'll file a bugzilla request though, since I think gcombust is much more intuitive, especially for less technically inclined users.
Thanks, Steve
On Sun, 31 Aug 2003 16:51:02 -0500, you wrote:
I think that the answer to my question is that a lot of people like xcdroast better than I do. ;-)
I'll give it another try.
I'll file a bugzilla request though, since I think gcombust is much more intuitive, especially for less technically inclined users.
Against gcombust is the fact that it is a GTK 1.2/Gnome 1 application and the author doesn't appear to have any interest in updating it to GTK2/Gnome2 (see his FAQ Q10).
Hi, The only time I switched back to Windows when i was a Linux newbie (and didn't realize there was one thousand other burning apps for Linux) was when i burned CDs. I really don't think that the average Linux user find xcdroast the most useful CD burning app, and that's what you are supposed to do, pick the best for us =)
//Erik
On Sun, 2003-08-31 at 23:10, Mike A. Harris wrote:
On Sun, 31 Aug 2003, Steve Bergman wrote:
I was just wondering why xcdroast gets included as the standard cd writer and not gcombust.
Why not $ONE_OF_A_THOUSAND other CD burner applications? Seriously, we can't ship every single application ever written in every application category. We can chip one or two apps for most important categories, but anything beyond that is distribution bloat, and should be in a separate repository such as fedora or another alternative repository, perhaps tied to the RHLP somehow.
By all means, file an RFE to have gcombust added to the distribution, that's the normal way things get added. There's no guarantee it will get added automatically of course, but at least it can be considered when we're investigating new packages next time around.
I always end up frustrated with xcdroast and gcombust is quite friendly.
The xcdroast UI is not perfect by any means, but I find it quite functional personally. I've been using it since it was a TCL/TK script.
Also, it's obvious how to write an existing iso image with gcombust and I don't see that xcdroast can even do it.
Well you're wrong there. 99% of what I use xcdroast for is doing just that.
Plus gcombust fits in nicely with Bluecurve and is at least a GTK app, whereas xcdroast is, well, whatever it is. I there a licensing issue or something?
Did you file a request in bugzilla? If not, file it against the "distribution" component. If you know the email addresses of any of the maintainers in the distribution of existing CD burning packages, you might want to carbon copy them as well. We investigate user suggested packages submitted to bugzilla every release. Some of them get accepted, some end up replacing an existing package in the distro, and some get rejected for one reason or another. It's best to have it in bugzilla however, so it can be tracked.
Then again, eventually, I suppose, nautilus will do it all.
Nautilus already can burn CDs.
Hope this helps.
On Sun, 31 Aug 2003, Erik Englund wrote:
The only time I switched back to Windows when i was a Linux newbie (and didn't realize there was one thousand other burning apps for Linux) was when i burned CDs. I really don't think that the average Linux user find xcdroast the most useful CD burning app, and that's what you are supposed to do, pick the best for us =)
That's definitely a reasonable thing. However, it's important also for people requesting enhancements, or changes of any kind, to not only discuss them on the mailing lists, etc. but also to file any important requests in bugzilla so that we're aware of them when the time comes to make those types of decisions.
I agree with you though about choosing friendly applications, and I'm sure there are more user friendly GUI interfaces to CD burning than xcdroast, even if I get along ok with it. ;o)
On Sun, 2003-08-31 at 22:25, Steve Bergman wrote:
I was just wondering why xcdroast gets included as the standard cd writer and not gcombust. I always end up frustrated with xcdroast and gcombust is quite friendly. Also, it's obvious how to write an existing iso image with gcombust and I don't see that xcdroast can even do it. Plus gcombust fits in nicely with Bluecurve and is at least a GTK app, whereas xcdroast is, well, whatever it is. I there a licensing issue or something?
Then again, eventually, I suppose, nautilus will do it all.
Is this a complaint about the nautilus cd burner capabilities or are you just not aware of them? Its not meant to be a highly complex burning application, but to be usable for people who are not aware of the details about cd writing.
To burn a iso file: right click on it and pick "Write to CD..." in the menu. Then select CD writer and click on the write button. From the command line you can just run "nautilus-cd-burner <iso-filename>".
To create a new CD, select "Go -> CD Creator" in the menu, or enable magicdev and just insert a blank cd. Then drop the files you want into the window and click on the cd writing icon in the toolbar.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an old-fashioned pirate dwarf in a wheelchair. She's a hard-bitten junkie former first lady with the power to see death. They fight crime!
On Mon, 2003-09-01 at 06:02, Alexander Larsson wrote:
Then again, eventually, I suppose, nautilus will do it all.
Is this a complaint about the nautilus cd burner capabilities or are you just not aware of them?
Not an intentional complaint, but I confess I short changed Nautilus' capabilities. What I meant was that someday Nautilus would be a full featured CD writer. I just didn't realize that it was already pretty much there.
Very nice!
I just created a CD from an iso, erased it and turned it into a music CD, erased that created a regular data CD. All very simple and very well integrated with the rest of the desktop. And the user doesn't have to know anything about DAO, TAO, Burn-Free, etc.
Anyone who needs more than this is probably going to be comfortable with xcdroast, or have their own personal favorite already, I suppose.
I have a couple of end users who will be delighted when I show them this tomorrow.
Thanks, Steve
On Mon, 2003-09-01 at 07:38, Steve Bergman wrote: ...
I just created a CD from an iso, erased it and turned it into a music CD, erased that created a regular data CD. All very simple and very well integrated with the rest of the desktop. And the user doesn't have to know anything about DAO, TAO, Burn-Free, etc.
Anyone who needs more than this is probably going to be comfortable with xcdroast, or have their own personal favorite already, I suppose.
I have a couple of end users who will be delighted when I show them this tomorrow.
The only thing I see missing is the ability to duplicate both data and music CDs. XCDRoast will duplicate data CDs. I would love to be able to backup my music CDs to something like an ISO Image. I have children who still get into my music collection and use my CDs for everything from Barbie tables to flying saucers... <smile>
If someone can help with this, I would appreciate it a lot.
Cheers,
Chris
-- ==================================== "If you get to thinkin' you're a person of some influence, try orderin' someone else's dog around." --Cowboy Wisdom
On Mon, 2003-09-01 at 15:59, Christopher A. Williams wrote:
On Mon, 2003-09-01 at 07:38, Steve Bergman wrote: ...
I just created a CD from an iso, erased it and turned it into a music CD, erased that created a regular data CD. All very simple and very well integrated with the rest of the desktop. And the user doesn't have to know anything about DAO, TAO, Burn-Free, etc.
Anyone who needs more than this is probably going to be comfortable with xcdroast, or have their own personal favorite already, I suppose.
I have a couple of end users who will be delighted when I show them this tomorrow.
The only thing I see missing is the ability to duplicate both data and music CDs. XCDRoast will duplicate data CDs. I would love to be able to backup my music CDs to something like an ISO Image. I have children who still get into my music collection and use my CDs for everything from Barbie tables to flying saucers... <smile>
If someone can help with this, I would appreciate it a lot.
Yes, this is one of the few features that was originally in the nautilus-cd-burner feature list. Its really a common operation for people that should be really simple. However, I haven't had time to work on it. If anyone is interested in this I'd appreciate that a lot.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an all-American coffee-fuelled sorceror She's a cosmopolitan impetuous research scientist living on borrowed time. They fight crime!
On Mon, 2003-09-01 at 15:38, Steve Bergman wrote:
On Mon, 2003-09-01 at 06:02, Alexander Larsson wrote:
Then again, eventually, I suppose, nautilus will do it all.
Is this a complaint about the nautilus cd burner capabilities or are you just not aware of them?
Not an intentional complaint, but I confess I short changed Nautilus' capabilities. What I meant was that someday Nautilus would be a full featured CD writer. I just didn't realize that it was already pretty much there.
Very nice!
I just created a CD from an iso, erased it and turned it into a music CD, erased that created a regular data CD. All very simple and very well integrated with the rest of the desktop. And the user doesn't have to know anything about DAO, TAO, Burn-Free, etc.
Anyone who needs more than this is probably going to be comfortable with xcdroast, or have their own personal favorite already, I suppose.
I have a couple of end users who will be delighted when I show them this tomorrow.
One comment about the current music cd burning abilities. This is very limiting and will in the future be removed in favour of a "burn playlist" button in the media player (rhythmbox for instance).
There just isn't any sane way to handle ordering of the songs in the nautilus UI. Plus you want to know things like total play time and have easy preview of the songs.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an all-American pirate inventor looking for 'the Big One.' She's a chain-smoking winged detective with her own daytime radio talk show. They fight crime!
Sorry for stepping up so late (I've been on vacation).
On Mon, 2003-09-01 at 17:28, Alexander Larsson wrote:
One comment about the current music cd burning abilities. This is very limiting and will in the future be removed in favour of a "burn playlist" button in the media player (rhythmbox for instance).
Excuse me, but this is more than counterintuitive -- I asked my wife where she would look for something to burn her music on CD and it was definitely not the music player -- and she is an end user (beat this ;-). Funny enough, she would expect a CD-burning application which kinda makes sense since the task probably gets perceived rather as "burn a CD" (with whatever contents) than as "do XYZ with my music" or "do XYZ with my data" -- putting a medium in the drive could be more "tangible" than shuffling bits around, but I'm getting philosophic...
There just isn't any sane way to handle ordering of the songs in the nautilus UI. Plus you want to know things like total play time and have easy preview of the songs.
Hypothetically asked (meaning I don't want you to commit to anything): Would it be that hard to implement a new Nautilus view which were aware of ordering and other stuff needed for that? Of course (Havoc will hate that) it would need to expose some of the innards of audio CDs and CD-ROMs, red, orange and other coloured books to the user, but I guess this could be done easy for easy tasks (copying whole audio+data CDs, burning ISOs, burning just data) and still provide means to do more sophisticated stuff...
But probably I'm the wrong person to ask -- getting ACL support into Nautilus wasn't as easy as I thought either ;-). If it'd be doable, I'd try my luck though (if time permits).
Nils
On Sun, 2003-09-07 at 23:04, Nils Philippsen wrote:
Sorry for stepping up so late (I've been on vacation).
On Mon, 2003-09-01 at 17:28, Alexander Larsson wrote:
One comment about the current music cd burning abilities. This is very limiting and will in the future be removed in favour of a "burn playlist" button in the media player (rhythmbox for instance).
Excuse me, but this is more than counterintuitive -- I asked my wife where she would look for something to burn her music on CD and it was definitely not the music player -- and she is an end user (beat this ;-). Funny enough, she would expect a CD-burning application which kinda makes sense since the task probably gets perceived rather as "burn a CD" (with whatever contents) than as "do XYZ with my music" or "do XYZ with my data" -- putting a medium in the drive could be more "tangible" than shuffling bits around, but I'm getting philosophic...
A cd burning application would be a pretty bad ui for burning an audio CD, since in them you can't easily listen to the tracks, find the music from your library, view id3 information, see how many minutes the current list of music is, etc. Unless of course this was a specific audio-burning-app. But then, if it were, it would be pretty close to a music player. The macos X music player iTunes has a burn button. End users seem to have no problem understanding it.
There just isn't any sane way to handle ordering of the songs in the nautilus UI. Plus you want to know things like total play time and have easy preview of the songs.
Hypothetically asked (meaning I don't want you to commit to anything): Would it be that hard to implement a new Nautilus view which were aware of ordering and other stuff needed for that? Of course (Havoc will hate that) it would need to expose some of the innards of audio CDs and CD-ROMs, red, orange and other coloured books to the user, but I guess this could be done easy for easy tasks (copying whole audio+data CDs, burning ISOs, burning just data) and still provide means to do more sophisticated stuff...
It is hard to get the ordering data from a audio-specific burn: view, and the view would be both hard to find, and quite a lot of work to write.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a world-famous moralistic jungle king with a passion for fast cars. She's a psychotic African-American queen of the dead with a song in her heart and a spring in her step. They fight crime!
On Monday 08 September 2003 05:21 am, Alexander Larsson wrote:
The macos X music player iTunes has a burn button. End users seem to have no problem understanding it.
As I understand it, the GUIs for CD/DVD are mostly wrappers around the command-line tools, so that kind of functionality can be placed anywhere. Evolution could offer a "burn" button to archive email, for example. No one would have trouble understanding that function either.
On Mon, 2003-09-08 at 11:21, Alexander Larsson wrote:
On Sun, 2003-09-07 at 23:04, Nils Philippsen wrote:
Sorry for stepping up so late (I've been on vacation).
On Mon, 2003-09-01 at 17:28, Alexander Larsson wrote:
One comment about the current music cd burning abilities. This is very limiting and will in the future be removed in favour of a "burn playlist" button in the media player (rhythmbox for instance).
Excuse me, but this is more than counterintuitive -- I asked my wife where she would look for something to burn her music on CD and it was definitely not the music player -- and she is an end user (beat this ;-). Funny enough, she would expect a CD-burning application which kinda makes sense since the task probably gets perceived rather as "burn a CD" (with whatever contents) than as "do XYZ with my music" or "do XYZ with my data" -- putting a medium in the drive could be more "tangible" than shuffling bits around, but I'm getting philosophic...
A cd burning application would be a pretty bad ui for burning an audio CD, since in them you can't easily listen to the tracks, find the music from your library, view id3 information, see how many minutes the current list of music is, etc. Unless of course this was a specific audio-burning-app. But then, if it were, it would be pretty close to a music player. The macos X music player iTunes has a burn button. End users seem to have no problem understanding it.
Point re iTunes taken. I don't know what to make with your other arguments -- you seem to be talking about a monolithic standalone app like xcdroast, gcombust. I want to see this in the context of a shell (what Nautilus seems to me -- it's way beyond being a mere "file manager"). It already can "preview" music tracks, id3 (or ogg metadata) would be just another set of object properties and aggregated properties (like "duration of current selection" in this case or in a more file-centric way "chmod of 200 files at once") is a feature missing which is long overdue (IMO).
There just isn't any sane way to handle ordering of the songs in the nautilus UI. Plus you want to know things like total play time and have easy preview of the songs.
Hypothetically asked (meaning I don't want you to commit to anything): Would it be that hard to implement a new Nautilus view which were aware of ordering and other stuff needed for that? Of course (Havoc will hate that) it would need to expose some of the innards of audio CDs and CD-ROMs, red, orange and other coloured books to the user, but I guess this could be done easy for easy tasks (copying whole audio+data CDs, burning ISOs, burning just data) and still provide means to do more sophisticated stuff...
It is hard to get the ordering data from a audio-specific burn: view, and the view would be both hard to find, and quite a lot of work to write.
I think we (both/all) have been overseeing a possibility how this could be done without the need to extend every application (and their aunt) that copes with data that possibly could be written to a CD (attention: proposal ahead):
- we already have a "CD burning view" (burn:///) as part of the "shell" (Nautilus), it would be best if it were easy to reach per icon on desktop and/or menu entry - we have applications that handle multimedia files (rhythmbox, xmms, xine, totem, mplayer, ...) - let the CD burning interface accept drops from the aforementioned applications (apps would need to be extend to send drag/drop events eventually, but this would be a generic extension, not specific to cd-burning) - hardest part: extend CD burning view to sensibly handle all the possible types of data, DnD wise ("Burn as files or CD-Audio tracks?") as well as on the presentation side (how to list what gets burned).
Offtopic: Bonus points for hiding URL-protocols behind something like "Burn on CD:", "Filesystem:", "World Wide Web:", "Secure World Wide Web" with nice icons in the URL line for great power ;-).
Finally: I think it would be better to pull the strings between the various views on the problem (files/CD burning/media) together in the shell than in the applications themselves -- I'd like to keep CD-burning specific code in them to a minimum -- perhaps just DnD as described and (where sensible) a "Burn this" button which only knows how to call the program that "burns this" on CD.
What do you think?
Nils
On Mon, Sep 01, 2003 at 01:02:01PM +0200, Alexander Larsson wrote:
To create a new CD, select "Go -> CD Creator" in the menu, or enable magicdev and just insert a blank cd. Then drop the files you want into the window and click on the cd writing icon in the toolbar.
This operation does not feed cdrecord from stdin via mkisofs, as one could reasonably expect, but builds a temporary iso image in /tmp. If there is a way to change that location it is so well hidden that so far I failed to find it. A corollary is that you better have enough of a disk space in /tmp or you will run into troubles; more so if /tmp is a part of /. Overflowing / is a barrel of fun.
It is hard to think of a good reason why these "real" iso images on a disk are really created here. They tend to stick around, for example, in abnormal termination conditions. Maybe the idea was that some of material to put on CD is mounted over a network and a network is slow or unreliable? Local networks in practice tend to be fast enough. Shrug!
If /tmp is not that big and you have space on some other file system you can "bind-mount" /tmp from there (early enough in a boot process or some things may "vanish" :-). Such workarounds were likely not intended for drag-and-drop crowd.
Michal
On Mon, 2003-09-01 at 17:52, Michal Jaegermann wrote:
On Mon, Sep 01, 2003 at 01:02:01PM +0200, Alexander Larsson wrote:
To create a new CD, select "Go -> CD Creator" in the menu, or enable magicdev and just insert a blank cd. Then drop the files you want into the window and click on the cd writing icon in the toolbar.
This operation does not feed cdrecord from stdin via mkisofs, as one could reasonably expect, but builds a temporary iso image in /tmp. If there is a way to change that location it is so well hidden that so far I failed to find it. A corollary is that you better have enough of a disk space in /tmp or you will run into troubles; more so if /tmp is a part of /. Overflowing / is a barrel of fun.
It is hard to think of a good reason why these "real" iso images on a disk are really created here. They tend to stick around, for example, in abnormal termination conditions. Maybe the idea was that some of material to put on CD is mounted over a network and a network is slow or unreliable? Local networks in practice tend to be fast enough. Shrug!
If /tmp is not that big and you have space on some other file system you can "bind-mount" /tmp from there (early enough in a boot process or some things may "vanish" :-). Such workarounds were likely not intended for drag-and-drop crowd.
ATM the only way to override this is setting TMPDIR in the environment. The code was initially written this way to avoid problems on machines with slow machines, or misconfigured systems where the cd writer is on the same IDE channel as the source.
I guess this could left non-default and used as a backup on such systems though...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an otherworldly chivalrous dwarf with nothing left to lose. She's a high-kicking mute traffic cop from the wrong side of the tracks. They fight crime!
-
Alexander Larsson -
Christopher A. Williams -
Erik Englund -
Gerald Henriksen -
Hoyt -
Jos Vos -
Michal Jaegermann -
Mike A. Harris -
Nils Philippsen -
seth vidal -
Steve Bergman