Monday, 24 May 2010

Let's make users' lives easier!

Zeitgeist can already make users lives really easy (see my last Awn + Zeitgeist post), but we don't have to stop there, one of things I'd really like to see would be if applications helped us with this - if the apps expose which URI they are currently working with (which file is currently open / web page currently viewed / ...) we can make very precise queries as to which other files (or contacts, web pages, applications etc.) are related to this URI.

As everyone likes examples imagine that you're working with a spreadsheet and zeitgeist knows that the last time you were working with it you were checking, had last_years_report.pdf open and were talking to xyz. Therefore it will provide you these options in some kind of menu (or dock / indicator / windicator). Wouldn't it be great?

To make this possible I suggest new X property for windows (let's say it'd be "_NET_WM_CURRENT_URI") and the only thing required by the apps is to set this property when a file is opened and update it when appropriate. If people like this idea I can prepare a patch for gdk (adding gdk_window_set_current_uri_hint) and libwnck (which would expose the property for pagers). Or perhaps there is already something similar what I missed?



  1. Sounds like a good idea, though I wouldn't know enough to know if it already exists. I wonder if it would be good to be forward-thinking and expose it as an array if possible. Web browers, image editors, IDEs, and note apps (Tomboy/Gnote) all could have multiple such things. Maybe the spec would just say to semi-colon separate mutiple URIs.

  2. You should probably ask window manager developers about this, instead of random blog visitors. Nepomuk-KDE developers might also be interested in coordinating this with you.

  3. I don't know about others, but that's totally not how computers work for ME. Chatting with others is mostly not related to my work at all. I have many different things open all the time that don't relate to each other.

    From my perspective your use case seems very constructed, like you have a solution in search for a problem.

    Also you ask for comments, but your blog makes it kind of hard to comment, because I can't even comment, without having an account somewhere.

  4. Go and discuss this on Freedesktop's XDG mailing list! I think it would be very useful, but that's not going to be easy to agree on this. I'd had tried about making WM_CLASS always matching the .desktop file name to allow identifying windows<->apps, but not everybody is happy with this kind of solution... So good luck!

    BTW, my pet feature would be that workspaces are used when computing links between files, so that you can work on several distincts contexts without mixing everything together. So only URIs opened on the same workspace would be considered as related.

  5. @Michael: I was also thinking about an array of uris, but I think that most of the time focus is only on one specific uri - the idea would was to update the property when the application switches tab.

    @majewsky, milanby: Yes, I'll send it to fdo, I wanted to see some reactions first.

    @Michael: It's only question of algorithms, we don't have to automatically assume that everything that you have opened is related to the document you're working on.

  6. Not everyone use several workspaces and as far as a web/mail/text user is concerned, the context (current activity) is defined by the focused window.

    In this assumption, proposed URIs can be :

    - RecentlyUsedFile
    - MostUsedFile
    - App.RecentlyUsedWith
    - App.MostUsedWith
    - App.File.RecentlyUsedWith
    - App.File.MostUsedWith
    - File.RecentlyUsedWith
    - File.MostUsedWith

    I would love to have some of these displayed in an indicator. My proposed ordering is:

    if context==desktop
    ProposedURIs=RecentlyUsedFiles then MostUsedFiles

    elseif context==App
    ProposedURIs=App.RecentlyUsedWith then App.MostUsedWith then MostUsedFiles

    elseif context==App.File
    ProposedURIs=File.RecentlyUsedWith then File.MostUsedWith then MostUsedFiles

    If an URI is already displayed, do not display it again.

    If I give it a mental try to my current desktop state the indicator should display :

    "".RecentlyUsedWith #1 (
    "".RecentlyUsedWith #2 (#zeitgeist irc channel)
    "".RecentlyUsedWith #3 (
    "".MostUsedWith #1 (Google)
    "".MostUsedWith #2 (Zeitgeist Project on Launchpad)
    "".MostUsedWith #3 (
    MostUsedFile #1 (This mailing list I'm answering a lot to)
    MostUsedFile #2 (my girlfriend Empathy contact name)
    MostUsedFile #3 (workproject.odt)

    I don't know if this example is convincing or even relevant, but I think this approach could radically change the way people are working on a project or doing simple tasks such as writing a comment.

    The next question needing an answer is : what will be the impact on the user's workflow?
    I hope we'll soon have the answer!

  7. This is something that I personally would like (KDE/Plasma/Nepomuk guy here) to see.

    From the 4.5, we'll have support for registering URIs with WIds (for the apps that want to) but right now it doesn't go via X.

    The things to consider are the following:
    1. One window can have multiple URIs loaded
    2. Sometimes, a title of the document could be useful
    3. Sometimes even a pixmap of the document could be cool to have


  8. @Ivan: So what do you use? DBus? Also I agree that there may be multiple URIs in one window, but most of the time only one is "focused", isn't it?

  9. Yes, at the moment we use d-bus and the info is stored in Activity manager service, but an X property would be cool (I'm not in KWin dev group, so I can talk only from a Plasma/Nepomuk POV).

    As for one focussed URI - it is true most of the time (not always obviously), but from my POV, registering only that one would be limiting.

    1. Having the info of all open docs would be rather cool for the taskbar (document-oriented vs task-oriented management).

    2. Knowing that a group of docs is opened at the same time can be used for semantic linking.

    3. Automatic ranking/scoring the most used documents - if the application reports the same URI multiple times only because the user is switching from one open doc to another, the system that would track it would mistakingly think that that document is rather 'popular'.

    There are certainly more reasons, but I'm a bit sleepy at the moment :)

    Anyhow, I don't really see a reason against supporting multiple URIs - implementation-wise, it is just a matter of serializing the list as URI1\nURI2\n...