Re: cd burning in gnome

[snickell stanford edu]

I beg to differ. "GUI"s that are wrappers for a command-line executable 
have consistently presented terrible interfaces to the user. I can think 
of few exceptions (actually, I can think of no exceptions, though I'm 
sure there are a couple because its certainly not impossible to do this 
well, it just virtually never happens: the very nature of the 
exceptions is that I would never have NOTICED that they are actually 
driving a command).  Libraries that are used by both a command-line 
client and a GUI tend to turn out better. Still, at times they suffer 
from the same problem if the library is too high level and wasn't 
designed primarily to drive a graphical interface (look at video-lan for 
a good example of a program that seems to suffer from this problem).

I think the perspective of a "non graphical core" (whether that's 
packaged as a seperate executable or a library) driving different 
pluggable "shells" (GNOME, KDE, etc) usually turns out poorly.

-Seth

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