What I’ve got open

Rather a lot, I find myself having to save a file somewhere temporary like my desktop just in order that I can immediately upload it to some website, or attach it to an email, or something similar. It’s irritating. I have to explicitly save it; I have to think up a name for it; then I have to switch to my mail client or my web browser and browse back to the file I’ve just saved and choose it by name to upload/attach it; then I have to browse to it again in the file manager and delete it. Now, there’s lots of talk about draggable icons for files and so forth, so I can just drag the save icon out of, say, the Gimp directly into the browser. The ROX apps do this; Risc OS did it too. That’s a nice long-term goal, but it requires touching every app in the universe, and it’s hard.

I had a thought about a workaround. It’d be quite cool to have a folder called “Open Documents” which, when opened, showed an icon for each document available in each application. Then, when you pick a “file” from this “folder”, it tells the relevant application “save it as some random temporary name” and then attaches/uploads some random temporary name. So you don’t ever have to manually do the save/delete thing.

I only really strictly need this for the Gimp, to be honest; I don’t upload textual files, I cut-and-paste them. So, a rather crufty approach:

  1. Download gimpdbusapi.py and put it in $HOME/.gimp-2.6/plug-ins/ and mark it executable. It’s a Gimp extension which makes two functions available over D-Bus: image_list and save_as. (This could be the starter for making all Gimp functions available over D-Bus, with a __getattr__ hook, the gimp.pdb object, and a bit of introspection.)
  2. Download gimpfs.py, a Fuse filesystem in Python, which talks to the Gimp extension via D-Bus to get the list of currently open images in the Gimp (even if they haven’t been saved).
  3. Create an empty folder ($HOME/Open?) and python gimpfs.py $HOME/Open to mount the view of Gimp open documents on that folder.

There might be better ways to do this, with gvfs and so on, and it would be way better if it didn’t have to use tempfiles, and so forth, but this is a proof of concept. What would need to happen to have all Gnome apps’ currently open documents automatically appear in a folder ready for choosing?

13 comments.

  1. I would love to be able to drag a gimp window icon from the window list applet onto the browser. Just thought I’d add that.

  2. OSX has some things: In the API, you can set the “Represented document/file” of a window, and it gets the icon of the file, and you can drag it like a file. Not many discover it, I think.

  3. Wrong approach, totally. Why don’t you do it like KDE does? You just drag an URL or image to whatever file upload input field or mail compose widget you want, and click send. KIO autodownloads and autosends the file correctly without you having to do the intermediate steps you described.

  4. Cool idea, not really new but definitly nice to have. (Pro Engeneer has something like that for example). I think it would be best do add this somewhere in gio so most apps will have that immediately.

    @Rudd-O: That’s cool! But the average user will never find out as it’s not really obvious (at least to me). So - good idea but too geeky!

  5. Rudd-O: so, I can have a file open in a KDE application, and then drag something into a file upload input field and it’ll upload the file I’m editing even though I haven’t saved the changes? What do I drag? Imagine I’m editing an image in some KDE image editing program. What do I drag to the file upload field in my browser?

  6. GIMP supports XDS, a protocol that allows you to ask an application to save a file where you dropped it. So you don’t actually need all this. If you enable the image preview in the toolbox, you can simply drag the image from there to your file-manager and GIMP will save the file in the folder you dropped it to. Recent versions of Nautilus support this protocol.

    You can also drag from the GIMP “Images” dialog and also from the list of unsaved images you get to see when closing GIMP.

  7. What is wrong with copy/paste? In kolourpaint (kde paint app) you just select the image (or a part) click copy, open KMail click paste, give a name to your creation and that’s it.

  8. I think this is an awesome idea.

    I like KDE’s kioslaves, too, but this is an awesome idea. Thanks for thinking up a cool idea.

  9. Of course GIMP also supports the clipboard. But it appears that Evolution lacks a (discoverable) way to paste something so that it becomes an attachment.

    It would definitely be nice to see this improved. And to see more applications (like your web browser and your mail client) to gain support for the XDS protocol.

  10. Another hint after looking at your Python code: It’s more efficient to create a layer from the projection than to duplicate the image and flattening it. This is new in GIMP 2.6 and the procedure is called gimp-layer-new-from-visible. You will note the difference in particular with large images as gimp-layer-new-from-visible uses copy-on-write and as such does not need to allocate a copy of the pixel data. And you will keep the alpha channel.

  11. Mathuzalem will resolve this kind of problem ( http://live.gnome.org/Mathusalem )

  12. Sven: I completely agree that XDS is the long-term solution to this (that’s why I mentioned the Rox desktop at the top of the article, which uses XDS everywhere). However, most apps don’t support it yet; specifically, Firefox and Evolution (as you note) don’t support it for uploads and attachments, which is what I want this for. This is an interim approach to solve the problem while we wait for XDS to be supported in every app. I don’t want to use XDS to Nautilus because then I still have to explicitly save my image, upload it via Firefox, then delete it afterwards. If I could XDS directly into Firefox that’d be great, but until then my open-documents hack keeps me going. (And thanks for the gimp-layer-new-from-visible note!)

    miro: you can’t copy-and-paste an image into a Firefox upload form. It’s rather cool that you can into KMail, though (and Evolution should support that!)

    Roumano: I don’t understand how Mathusalem addresses this problem. Can you explain in more detail?

  13. [...] Document Representations November 25, 2008 — Daniel In response to Stuart: [...]

Post a comment.