Try disabling the http URI handler for GNOME. <gconf:///desktop/gnome/url-handlers/http/enabled>
When you click a link to a PNG image, EOG starts up. Click a link to an M3U file, and Totem starts up. What happens, is that GNOME-VFS determines the MIME-type of the target file with a HTTP HEAD request, and, exactly the same as with local files, automatically starts the preferred application with that URI. This hack is definitely rough and ready, what is needed to bring this idea truly to life is: 1. An "open URI/location/whatever" button/text entry somewhere easy to grab on the panel. As it happens, deskbar uses gnome-open when you type a http URI, so this kind of works. The same cannot be said, however, of file URIs. 2. A simple web page viewer, sans-location entry. Something that embeds Mozilla and calls gnome_vfs_show_url on any click-throughs. 3. A favourites system, allowing you to bookmark favourite web pages, pictures, sound files, spreadsheets, documents, web folders (dav/ftp), etc. all *by URI*. One click should invoke the file-open process. 4. A UI for user-feedback and confirmation. When clicking links in IM conversations or opening a resource by URI, the user should be prompted with both feedback when the file is taking a while to determine the file type of, and also basic information about the file. E.g., Jane sends me a link to <http://herwebsite/somepicture> I have no idea what that is, so when I click it I should be told that "This is a JPEG image of size 534 KiB." I should be asked "How would you like to open it?" and be given a list of capable applications from XDG. Optionally, we could detect that if the resource is not on local storage (i.e. its URI scheme is not "file"), we can prompt the user to save it, and invoke a transfer. Preferences should be remembered if requested. For example, I don't want to be prompted to open a web page every time I click a link. 5. A "navigation trail" system, whereby clicking links from one thing to another (e.g. Jane -> Her Picture) will be saved in memory somehow. Applications can then find out how the user arrived at that document, and implement a "back to where I came from" button. I think this is vastly superior to classic "back-forward" navigation, as more and more often, our behaviour of browsing the web does not fit that model. Kind of clashes with the Spatial paradigm when you open one file from two separate origins, but I'm sure we can think of something clever. 6. More file-opening applications supporting a "Save As" action. E.g. Totem. When I click a link to an Ogg film on my friend's website, if I tell Totem to fire up, I should still be able to save the file to a new location without having to invoke the URI open prompt again. What this effectively does, is gives us a "My Favourite Stuff" feature, where you can put almost anything that is addressable via a URI. (Yelp pages, anyone?) It also dissolves the concept of a web browser into the desktop platform, which I think is a radical but important step. Why have two platforms? If I open an image/svg+xml on my desktop, it opens in EOG. If I open one in a browser, it opens in the browser's helper application. Though it doesn't remove the entire need for browser helper applications (after all, people still want to embed videos, etc., in web pages), it does make the desktop experience much more consistent. Think things that you can't (or shouldn't) embed into a web page, such as PDFs. If I click a link to a PDF, I don't want it to save it permanently on my desktop and then open in Evince. I don't want it to embed into my web browser. I just want to see the PDF in the same way I'd see any other PDF, then think about where I want to save it (if at all) later. Yes, there are some problems with some web servers. Amazon, for example, don't handle HEAD requests at all, so there's no way for us to get info about resources other than by GETting them. This can be automatically handled in GNOME-VFS, just by disconnecting after the response headers have been sent. Also is the fact that two connections need to be built up. One by the invoking app for the file info request, and one by the invoked app for the content request. This can be alleviated by moving the existing HTTP pooling stuff into the GNOME-VFS daemon, which apparently is as easy as editing a configuration file. This way, both a HEAD and a following GET exist in the same persistent HTTP connection. Yay! So, if you read this far, you are obviously very bored or very interested. Please let me know what you think. Thanks! ♥ GNOME -- Alex Jones <[EMAIL PROTECTED]> _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list