Older blog entries for funrecords (starting at number 18)

I spent my precious time today building gnome from cvs. Why I did this i'm not sure... Well at least for the most part it now works. Notable exceptions are evolution (which I can live without), storage (just a toy at this time anyway) and gaim (the lack of gaim does kind suck.). Anyway I think this link summarizes the day well.

For those that are too lazy to click the link: "If we truly understand that the internet is shit then maybe we'll go back to looking elsewhere to check our information instead of just Google...If we remember that the medium isn't the message then maybe we'll stop aimlessly surfing for something amusing when we could actually be doing something fun."

It's Official, Hell has Frozen Over

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.

Everything you buy will eventually be thrown away.

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..."

Awesome!!!!

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...

aldug: Instead of forking gnome-open processes, you can launch the default gnome web browser using gnome_url_show from libgnome. The advantage of this is that gaim can still be used with gnome2.2 (assuming it doesn't have any gnome2.3 depends). Only real problem is that gnome_url_show can block when doing mime sniffing synchronously. It would be nice if gnome-vfs provided an asynchrounous implementation. Open Applet has a hacked async function, but the more I think about it, the more hacky it looks. I need to talk to alex about how to do this the "correct way" in gnome-vfs
Too Much Hacking For One Day

As the Changelog will show, I spent way too much time hacking on OpenApplet today.
I'm sure the next time I go look at the code I'll end wondering what the hell I was thinking :P

Anyway the list of new features includes:

  • Asnychronous loading of urls so that the ui doesn't lock up while mime sniffing remote files.
  • Progress dialog while a remote file is being loaded.

    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.

    Vicious on Code Quality

    "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."

    Tabbed MDI Strikes Mozilla Again

    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.

    Desktop Wide Bookmarks

    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 [1] bookmarks and a "More Bookmarks..." menu item. Selecting "More Bookmarks..." opens the bookmarks folder [2], 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. [3]

    Question and Answers

  • Why not list all bookmarks in the bookmarks menu using hierarichal menus? [4]

    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.

  • Why File->Bookmark?

    File is the most correct menu in which to place this entry. All document actions appear in this menu including print and save.

    [1] Note I say "most used" and not "most recently used" there is a difference.
    [2] I use the term "folder" loosely here, it need not be a unix directory.
    [3] Of course for this to work we're going to need a cross-desktop standard for bookmarks.
    [4] This assumes a hierarichal bookmarks system of course, which I actually don't support but thats another issue.

  • Open Applet Runs Into API Snags

    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 [1] 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 [2].

    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 [3]. 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 :/

    [1] Especially for those of us in the majority who still use dialup.

    [2] 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.

    [3] Libifying functions to provide UI would be useful to other apps that can open hyperlinked data such as irc clients, word processors etc.

    9 older entries...

    New Advogato Features

    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!