Re: cd burning in gnome

[Rodney Dawes <dobey free fr>]

alexl's suggestion seems the best way to do it. Maybe a comprimise
can be made though. I don't think that much GUI should be determined
by the application. There is really very little an application should
need to know about burning, if it wants to use it.

I also think it's best to keep as many optional things out of the
core gnome-vfs package as possible, and to keep it's size down. It
makes it much more maintainable for external modules, and helps keep
packaging/releasing easier to do, and prevents having to download
megs and megs of a single package, for a 5k change. It also keeps the
number of dependencies in the core library down.

Perhaps the best way is to have the burn: uri accept speed/size/etc...
arguments, which it then passes to a program that handles the GUI.
There will also need to be a sane way to deal with permissions for
writing to the device. This will require co-operation from the
distributions to handle correctly though. Aside from that, it all sounds
well and good.

-- dobey

On Thu, 2002-12-05 at 13:23, Alex Graveley wrote:
> Hi,
> 
> So there is some contention as to the correct way to implement CD
> burning inside nautilus/gnome-vfs for Gnome, and I was hoping to get
> some opinions from the community as to which is the better option.
> 
> Alexl thinks that a burn: vfs uri should only be used for temporary
> file-storage, and that a separate executable should be invoked to prompt
> the user with a dialog to begin burning and to show status.  The dialog
> will allow specifying options like burn speed, burner device to use, and
> a label for the CD.  The advantages here are simplicity of the burn: vfs
> method, and keeping cd-burning code out of gnome-vfs.
> 
> 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.
> 
> So, what do you guys think?
> 
> -Alex
> 
> -- 
>  on the canvass of life, incompetence is my paintbrush.