Re: cd burning in gnome

["Bowie J. Poag" <bpoag comcast net>]

(..snip..)

GUIs and device abstractions are two separate beasts.... You cant eat a
hammer, just the same as you can't drive nails with a loaf of bread. Sure,
you can have both, its not a good idea to mix the two. It produces nothing
useful.

Keeping the two beasts separate (and modular, for that matter) allows for
simultaneous improvements on both ends. Functionally down below, and
cosmetically up above. As far as Unix goes, GUIs have traditionally been
nothing more than wrappers for underlying executables anyway. Besides,
you'll have less of a mess on your hands in the long run by swapping out an
executable than you would swapping out code in and out of gnome-vfs. Simply
put, if somethings going to break, i'd rather be told that I simply need to
edit the arguments on an executable than be told I need to go on a wild
goose chase for a system library who's replacement may very well break
something else.

Beyond that, its a style issue. By having a GUI that addresses an
executable, you leave yourself an out --- If it breaks, you can still fix it
on-the-spot, which stays true to Unix philosophy in general.

Cheers,
Bowie J. Poag



> Hello,
>
> > 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.
>
> 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.
>
> Miguel.
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list