Re: cd burning in gnome
- From: Alexander Larsson <alexl redhat com>
- To: desktop-devel-list gnome org
- Cc: Alex Graveley <alex ximian com>
- Subject: Re: cd burning in gnome
- Date: Thu, 5 Dec 2002 13:45:55 -0500 (EST)
On 5 Dec 2002, 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?
It is technically possible to add some new API to gnome-vfs to allow
it to initiate the burn operation and communicate to it during the burn
(enumerating cdroms, selecting cdroms and parameters, getting progress
updates, checking availible space, parsing errors, loading new blank cds
etc). But such an API could as well be in a standalone library. In fact, I
know at least two people planning/writing "libcdrecord".
The question is, is gnome-vfs a good place for this API?
I want gnome-vfs to be a lean filesystem-switch kernel. It should only do
the things it absolutely has to, and no more. It should not be a random
dumping ground for operations that relate to I/O, especially stuff that
very few apps will use. If it can be done outside gnome-vfs it should
(unless there are performance reasons or other special reasons).
If someone wants to work on libcdrecord it would give the advantages
1, 2 and 3 that alexg cites, plus it would not be linked into every gnome
app, it would be on a separate API freeze and release schedule from
gnome-vfs and it would mean less burden for the gnome-vfs maintainers.
If someone actually implements[1] such a library (and its good, well
maintained, etc) I will consider switching nautilus-cd-burner to use it.
[1] Preston Brown at Red Hat actually has some of the work for this
library done, so anyone interested in it should talk to him.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl redhat com alla lysator liu se
He's a superhumanly strong misogynist paranormal investigator haunted by an
iconic dead American confidante She's a virginal extravagent soap star with a
flame-thrower. They fight crime!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]