CD burning with Nautilus, was: Why xcdroast and not gcombust?

[Nils Philippsen]

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
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20030908/72f8107d/attachment.sig>