Anyway the list of new features includes:
and why did this take me so much time?
Don't you love when you spend two hours searching for the source of a bug that ends up taking two lines to fix.
"Most code is absolute crap. GNOME, KDE, it's all mostly crap. Yet overall it generally works. If we just wrote beautiful code that is all theoretically correct and only uses nice well designed APIs, we wouldn't have shit...Unix APIs are utter shit...Same with X11. Let's produce free software desktops that work, rather then lots of beautiful code that will never be finished."
In attempt to deal with the monstrosity known as tabbed MDI, mozilla developers have now added a "Do you really want to close all these tabs" dialog, a variation on the horribly annoying "Do you really want to quit" dialog.
The solution to this problem is really not all that difficult. Instead of trying to deal with the data loss caused by allowing users to close a group of documents at once, simply only allow the user to close one tab at a time. Epiphany gets this right. The file menu close item only closes the current tab. If there is only one tab in a window, the window is closed. Now if I can only get them to implement the same behavior for the window border close button.
Why are bookmarks in the web browser only? It seems so limiting to me. Shouldn't any file or folder be bookmarkable?
Anyway here's my idea. Remove the bookmarks menu from every application that has one. Instead add a "Bookmarks" menu to the desktop panel menus. This menu would list the 15 most used  bookmarks and a "More Bookmarks..." menu item. Selecting "More Bookmarks..." opens the bookmarks folder , giving you access to all of your bookmarks and automagically opens them in the correct application.
How do I bookmark a page than? Well quite simply File->Bookmark should be available for every document. 
Question and Answers
Well hierarichal menus are slow and hard to use. The main goal of the bookmarks menu is to provide quick access to the most commonly used bookmarks. Including all bookmarks in the bookmarks menu makes the menu inefficient at which point a desktop launcher to open the bookmarks folder makes more sense. The bookmarks folder should provide quick enough access for less commonly used bookmarks.
File is the most correct menu in which to place this entry. All document actions appear in this menu including print and save.
 Note I say "most used" and not "most recently used" there is a difference.
 I use the term "folder" loosely here, it need not be a unix directory.
 Of course for this to work we're going to need a cross-desktop standard for bookmarks.
 This assumes a hierarichal bookmarks system of course, which I actually don't support but thats another issue.
For those not in the know, the open applet is a simple panel applet that allows you to open web address, file system files and folders, remote ftp files and folders, or search the web.
Well my originally simple panel applet has run into some issues. The function it uses to open a url with is gnome_vfs_url_show from GNOME VFS. The main issue is that mime-sniffing remote files is costly  and the sync i/o leads to a noticeable lockup in the ui. My original solution was to set application handlers for common schemes like http:// and ftp://. This works all fine and dandy until you consider the fact that opening a web browser to view a pdf file that just happens to be stored on a webserver doesn't really make sense nor does it make sense to open webdav directories in a web browser either .
What to do, what to do?
UI wise I have it all figured out in my head. For the most part mime-sniffing single remote files does not take that terribly long. On average I'd guess its taking about 5 seconds for the average website. I'd need to take a look at the GNOME HIG, but afair if an operation takes more than around 3-5 seconds some sort of visual affordance that work is being done should be provided. In the case of the open applet poping up a dialog which informs the user that the file is being loaded along with a button to cancel the operation would suffice . However the key here is to not block the main ui so that the user can open other urls at the same time that he/she is waiting for the blocked one/s.
One idea I had to avoid the worst of the UI locking was to fork off gnome-open processes instead of directly opening the url with gnome_vfs_url_show in my app. This would work but obviously wouldn't scale very well :/
 Especially for those of us in the majority who still use dialup.
 I believe kde uses webdav:// in this case, but to the best of my knowledge gnome's use of http:// is more correct. It doesn't really matter though, even in the webdav case you need to be able to sniff out the mime-type of the file to open.
 Libifying functions to provide UI would be useful to other apps that can open hyperlinked data such as irc clients, word processors etc.
hadess: The GNOME VFS method provided by sound juicer is a start but the ui still sucks due to the lack of steps 2 and 3. Expecting users to be familiar with gnome-vfs schemes is an even worst ui than using an application. 
Anyway, while we're on the subject of code, any chance this patch can get applied to gnome-mime-data. I need it so that the open applet can be used to open folders.
 Once again i'm not picking on sound juicer here specifically.
Ross Burton works on a nice little app called sound juicer. This app aims to provide a simple to use cd ripping interface. The thing thats strikes me though is the fact that no one ever thought "Hey this is a form of file management, lets put it into the file manager!" The file manager, what you say? Thats crack! Think again. The file manager provides the exact required interface here. Ripping cd's is just another form of managing your files (these just happen to cd audio tracks).
Dave's Proposed CD Ripping Interface
Compare the above steps to rip a cd to the similar steps to copying files from a floppy disk. *gasp* you can replace the term CD Player with floppy disk and rip with copy, and you have virtually the exact same steps.
Addendum, July 8th
I whipped up a quick mockup dialog for the UI mentioned above. One issue that came to mind is that users may not want to be bothered every time they try to copy files from an audio cd to a folder. This leaves us with two choices. A lesser designer might suggest adding a "Don't ask me again" checkbox, but as mpt says "oh, so you didn't really need to annoy me, but you thought you would anyway?." The other option is to provide the preferences from the within file manager preference dialog. The issue of a dialog vs preferences really requires two questions to be answered, "How often do users actually rip their cd's?" and "Will they most likely always choose the same format and endoding?" If the answers are quite often and yes, I think a preference available from the file manager preferences might be a better ui, if the opposite answers are true, than perhaps a dialog is better.
2:36 AM, time to go to bed....
 I do think these preferences are useful/necessary. A hi-fi audio fanatic will likely choose a high-bit rate to encode at, a linux geek will want to use OGG and your traditional file swapper will most likely want to use MP3.
In other news, I spent the day painting kitchen walls. It was kind of fun and I made a nice slice of cash as well, considering my current complete lack of income. I have now returned to my normal daily activity, staring at a computer screen.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!