Re: cd burning in gnome

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

I didn't say they were good, or even that I liked that sort of arrangement.
To use my exact words, "As far as Unix goes, GUIs have traditionally been
nothing more than wrappers for underlying executables anyway."  I usually
keep my personal opinions about GUI design myself.  Remember, Seth...
Reading in FUN-demental! :)   Besides, thats the whole point of abstraction,
isnt it? The only thing were arguing here is _where_ the abstraction should
be.... at the device level, or at the command level. Not whether or not GUIs
are pretty or not.

> I beg to differ. "GUI"s that are wrappers for a command-line executable
> have consistently presented terrible interfaces to the user.

I would argue that. A change of a library may break several programs,
whereas a change of an executable breaks none. You will still have the
ability to burn, no matter what. Hence, my remark about leaving yourself an
out --- Again, Reading is FUN-demental!

> Libraries that are used by both a command-line
> client and a GUI tend to turn out better.

Yes, yes, and i'm going to build an engine that runs on spotted owls and
bald eagle heads. Your logic doesn't hold up -- By keeping an executable in
place, by your same logic, allows multiple authors to write multiple
front-ends using multiple languages.

> 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).

It only turns out poorly in the hands of poor programmers. Drawing
comparrisons between shoddy code and shoddy methodology is a mistake.


Cheers,
Bowie

> 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
> >