Re: Floppy disk access in Gnome - followup.



Common sense, round IV:

On Tue, 2001-10-30 at 14:52, George Farris wrote:
> Yes this seems to be the general idea.  I have no idea what would be
> involved implementing this.  Writing a libmtools seems to be a thought.

General idea.. as in generally bad, broken, unportable, unpredictable,
inefficient, and insane?

> 
> And yes I know software other than GNOME (or rather maybe GTK+ if it was
> part of the GTK+ filedialog widget) wouldn't be able to use it right
> away but hopefully OpenOffice and Mozilla could be patched.

I can see this as an extension to GNOME-VFS.  If anyone is going to
waste so much of their time for something as silly and pointless as a
"hack" around an issue much more easily fixed elsewhere, it sure as hell
better be a plugin and not something forced onto me and other sane users
of GTK/GNOME.

Besides, file access all goes thru GNOME-VFS (or should, anyways, for
GNOME apps).  And unfortunately, at the moment, neither OO nor Mozilla
use GNOME-VFS.  Most GNOME apps (in 1.x) don't use GNOME-VFS to it's
full advantage.

I am sorry I'm sounding so pissed about this idea, but... *I am*.  I
still don't see why it is so hard to grasp that GNOME is a set of
libraries/applications for allowing the user to interact with programs
sitting on top of the system level.  GNOME doesn't provide TCP/IP, SMB,
hardware graphics rendering, DSP processing, power management, etc.  Why
the hell it should provide hard-ware level access to a floppy drive is
beyond me.  Yes, mounting is annoying.  But frickin fix the mounting
problem.  Don't avoid it.  This "general idea" is like trying to fix
road traffic by building a special set of roads just for owners of Volvo
products: it doesn't solve the problem for the rest of the world, it
only avoids the issue of traffic instead of solving it, and it would be
a considerable amount of time and money to do something that would've
been easier and cheaper fixed elsewhere (like the problematic roads). 
And Volvo's suck anyways (IMASHO, anyways :P )

Go ahead, make this GNOME-VFS plugin, it *would* be an improvement over
what we have now, for *some* users.  But I guarantee you'll end up not
being happy with it.  Save yourself the effort and time and start
helping out with either the kernel supermount project (for Linux users)
or a more powerful version of the automounter daemon; hell, a decent
automount daemon could plug into the kernel like imon/fam, so that some
systems would use the less robust and more inefficient polling method
while supported systems would get full kernel/hardware level support (I
believe Linux has something similar to this, no?).  That would be
ideal.  One interface for all supporting kernels, one
daemon/configuration for all platforms, and independance from any
GUI/user app.

If you can get enough support up for that, I'll definitely do what I can
to help.  ^,^  If you want to make poor attempt at emulating the kernel
fs layer, tho, well... good luck, in any event.  Maybe you'll somehow
manage to defy common sense and end up with a perfect solution. 
(*cough*, *cough*).  But really, good luck in any case.  ^,^

Sean Etc.

> 
> On Tue, 2001-10-30 at 18:20, Ian McKellar wrote:
> > On Sat, 2001-10-27 at 03:34, George Farris wrote:
> > > 
> > > (2)
> > > The next comment was that "You don't have to mount floppies - just use
> > > tar with the raw device (/dev/rfloppy or whatever)."
> > 
> > My personally preferred insane solution is to write a FAT gnome-vfs
> > module that knows how to access floppy devices directly. This is a
> > similar thing to what we do for Audio CD access in GnomeVFS/Nautilus.
> > This won't work with non-GNOME programs, but I don't really care about
> > them :)
> > 
> > Ian
> > 
> > PS: We could use the same magic for accessing MacOS HFS formated disks.
> -- 
> George Farris - VE7FRG
> George gmsys com
> _______________________________________________
> gnome-list mailing list
> gnome-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-list





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]