Yes it's true. This annoucement from Dave Camp, was sent to the nautilus mailing list today proclaming that Nautilus will now become an object oriented file manager (with an optional file browser). Frankly, I'm in a state of shock.
Moving and more specifically packing really depresses me. It really makes you realize how much crap you buy that you end up just throwing away. :/ Maybe I'm just a hippie with short hair but I find the act of throwing stuff away really upsetting. Well at least paper can be recycled.
Coolest Free Software Project Goes To...
"Storage is an exciting project to replace the traditional filesystem with a new document store. Storage is part of a larger design for a new desktop environment, more details on that to come. The current implementation offers natural language access, network transparency, and a number of other features..."
Just got back from seattle. I'm moving there at the end of august and needed to find a place to live. I'm off to wisconsin tonite to see Radiohead. Woot...
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.
Keep up with the latest Advogato features by reading the Advogato status blog.