Browser-based file downloads (was: Re: [vox-tech] browser and mimetypes (I think))

[Bill Kendrick]

On Sun, May 08, 2005 at 05:11:14PM -0700, Karsten M. Self wrote:
> The other issues you may have to deal with:
> 
>   - Browsers apparently use the MIME type information concerning a file
>     to figure out how to display it.  See above for the .desktop
>     clusterfsck WRT GNOME.  Used to be something you'd manage w/in the
>     browser.  Oh, except when they don't.

In KDE and Konqueror, this kind of stuff _is_ handled more globally,
but then, Konqueror's KHTML display functionality lives elsewhere outside
of Konqueror (such as in the tabbed browsing capabilities of the 'Akregator'
news feed manager/fetcher).

And other applications have abilities to do HTTP, FTP and other kinds
of downloading (such as KGet, obviously, but also pretty much any
other KDE program in which you can open a file... feel free to
download it over HTTP instead of pulling it off your hard disk ;^) )

Anyway, of course, KDE seems to do a reasonable thing.  When you go to
"Settings->Configure Konqueror" in Konqueror, you get a fairly intuitive
configuration window, and there's a big "File Associations" icon on the
left.  Click that to bring up those specific options.

When you go to KDE's main configuration center, the "Control Center"
(available from the "K" start menu), you find all of these same options
stored in reasonable places, though not all buried together under
"Internet & Network -> Web Browser"... again, because it's not _just_ the
web browser that handles these kinds of things.

So really, it depends on how you're going about it.  And to me, at least,
it does seem to make sense.  Though, everyone seems to agree that the KDE
Control Center itself is getting a little too overwhelming, and that the
tree hierarchy and search options on the left aren't the best way of going
about navigating your desktop environment's settings.


<snip>
>   - As noted above, some sites (mostly corprate fsckups dependent on
>     Java or Javascript) don't link directly to downloads, but to an
>     intermediary page.  Sometimes it's trivially possible to determine
>     the proper URL, sometimes not.  Worse:  d/l managers from Firefox
>     and Galeon (GNOME) fail to provide the specific URL currently being
>     fetched in a form that allows ready cut'n'paste to a terminal.  Or
>     at all.

<sacrasm> It's called "progress"!  Now let's go buy another "solution"
for $10,000...

-bill!