Re: cd burning in gnome

On Thu, 2002-12-05 at 12:47, Miguel de Icaza wrote:
> > I think cd burning should be integrated with gnome-vfs, such that
> > invoking a burn operation on a burn: uri will cause the cd to start
> > burning.  Burning options like speed/label/audio-or-data should be
> > passed as arguments here, instead of being locked up in a separate
> > executable.  The advantages here are that cd-burning is 1) easily
> > available to all applications, 2) that burning options, status, and
> > cancellation can be controlled through code and 3) that the GUI is
> > determined by the application.

> I prefer the Alex Larsson approach for a couple of reasons:
> 	* It is not clear when CD burning would begin with the
> 	  burn: uri.  
> 	* An ioctl/command setup is suboptimal, because
> 	  the burning process might have to deal with exceptional
> 	  conditions like defects on the CD, choosing a label,
> 	  retrying the operation.
> 	  These conditions would require either an elaborate
> 	  callback mechanism/notification mechanism that is
> 	  not really needed.
> 	* I fail to see the advantage of putting the burning code
> 	  in the gnome-vfs.  Using `burn:' as a staging place seems
> 	  like a small code addition, but using it as the actual
> 	  burning process produces no benefits, and makes the GUI
> 	  for burning more complex.
> 	* It just does not feel right.  

Ideally I'd like to see something like this:

- Low-level library, e.g. libcdrecord. This should have an API that 
  takes burn parameters, like session/speed/track specifications and 
  sources, as structs (or something equally simple). Make use of glib 
  here. I guess this would depend on mkisofs as well.

- CD writing dialog(s) in libgnomeui, or whatever UI library is 
  appropriate. This should know about libcdrecord, making it easy to 
  hook the UI up with the backend. Ease of use translates to actual use,
  which will make CD writing in GNOME a lot more consistent across apps.

- Gnome-vfs using the libcdrecord library to do file copy operations to 
  CD. This will make for few changes to the API, since the existing file
  copy infrastructure/error notification can be used, possibly with
  a few extensions. It won't cover all cases, but it'll cover the simple
  and most common case of blanking a disc and burning files to an 
  iso9660 track transparently.

I don't think gnome-vfs should deal with burning audio tracks.
Applications with specific needs can use the UI module and/or
libcdrecord directly.

The problems we'd address are 1) cdrecord/mkisofs binaries being
hard/hairy to interact with (leading to implementation disparity), 2) UI
inconsistencies and 3) API flexibility/integration.

I don't think another external binary with its own UI is the way to go,
anyway. If I've understood this debate and that's what it's about.

Hans Petter

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]