Go forward in time to September 2010.
Christian Hammond has been working on a very cool branch of GtkFileChooser to let you define roots for the file dialog. Normally, this is what my file chooser looks like — it lets me browse anything on my file system:
In the following screenshot, the file chooser has been rooted to show only my $HOME. Note that no volumes or shortcuts that are outsideof my $HOME show up in the shortcuts pane.
The API makes it easy.
GSList *roots; roots = g_slist_append (NULL, "file:///home/federico"); gtk_file_chooser_set_root_uris (chooser, roots);
And in the following example, the filechooser has been constrained to my $HOME and to /tmp:
This is basically the infrastructure we need to support proper lockdown in the file chooser. At some point it may be interesting for sysadmins to say, "don't let users wander in the filesystem, but constrain them to their home directory, the corporate shares and their USB stick".
The patches are not quite ready yet (in particular, passing a GSList of strings is not very nice for language bindings, I think), but it should be easy to fix for production. Any volunteers?
Yesterday I mentioned a patch for Evince to add an "Open Containing Folder" command. In the bug that tracks the patch, Milan Bouchet-Valat asked about having an X window property that apps could set to let the environment know the URI that is being shown in a window.
The basic idea is to add a _NET_WM_CURRENT_URI property to windows, whose value is a string with the URI of the document being viewed. From the application programmer's viewpoint, this would be something like gtk_window_set_current_uri (window, string). You would call that function when you load a document.
Gnome-shell and window managers could use this information to do several things — offer the "show in file manager" command themselves, provide information to Zeitgeist about the documents that are open at any one time, etc.
The discussion has an interesting mail from Luboš Luňák. It seems that KDE has already been considering something similar.
Extending the idea a bit further, gnome-shell has mockups to show a list of tabs that are open in your web browser. If you make that window property be a list of URIs (for all the open documents) instead of a single URI, then the window manager can list the open web pages easily. You would need a human-readable list of document titles (and possibly favicons and other nasties), but details, details...
I think we would also need some sort of message that the window manager can send to windows, like "focus this document" for when you select your tabbed web page in gnome-shell's lists. This message should be the only command that we add to communicate from the window manager to apps; in theory you should be able to do everything else from the app itself, once you have focused the documents — close the document, move it, etc.; there is no need to complicate the window manager with that knowledge.
For my Mexican friends — correlación entre municipios PANistas y violencia.
Remember the lack of bidirectional navigation in our document windows? The problem is that you can go down in the folder hierarchy with the file system until you open a file, but you cannot go up from the document app to visit the file system again.
I just made a little patch for Evince to add an "Open Containing Folder" command, similar to the one that Firefox has in its Downloads window.
This patch is is at bgo#627443.
Unfortunately, Nautilus currently seems to have a bug. If you launch "nautilus file:///blah/blah/foo.pdf", Nautilus complains that "foo.pdf is not a folder". I'm sure this worked at some point before — you could make Nautilus open a window showing a folder *with* a certain file already selected.
In the meantime, my patch for Evince just causes Nautilus to open a folder window. It would be nice if it could also select the file in that window.
Update 2010/Aug/20: My patchset is against the master branch. I've redone it for 2.28 and 2.30 as well, for if you are running older versions of Evince. You can do "git clone git://gitorious.org/evince/evince-document-centric.git" and look at these branches: unmessify-my-pdfs (master), unmessify-my-pdfs-2-28, unmessify-my-pdfs-2-30.
Go backward in time to July 2010.Federico Mena-Quintero <firstname.lastname@example.org> Thu 2010/Aug/19 18:02:39 CDT