Re: interapplication communication



On Tue, Jan 5, 2010 at 12:55 PM, Jose Aliste <jose aliste gmail com> wrote:
Hi,

see comments inline

On Tue, Jan 5, 2010 at 1:26 AM, Owen Taylor <otaylor redhat com> wrote:
> On Tue, 2010-01-05 at 00:02 +0100, Johannes Schmid wrote:
>> Hi Owen!
>>
>> > Why "without the [overview]"? - I can think of several reasons offhand
>> > why a task list might be preferred to the overview for window switching:
>> >
>> >  - You can look find a window with your eyes and then mouse directly
>> >    to it.
>> >
>> >  - There's less window motion, so it's easier to understand the
>> >    change when a window is raised or lowered and thus easier to
>> >    build a mental model of where things are.
>> >
>> >  - The overview takes a fraction of a second to come up, and more
>> >    if the shell is performing badly on your system.
>>
>> Combining the three above points: I see a problem that at least for me,
>> the overlay is kind of a context switch that I might not want when
>> should changing the window (for example, checking the download-window of
>> firefox, if the download has finished).
>> In GNOME 2.x I don't have a context switch here - I just bring a little
>> utility window to foreground with the tasklist.
>
> You are going to get a message window popping up in the message tray
> when the download completes. And you'll be able to click on the Firefox
> icon in the message tray area to see access your completed downloads
> (old messages), so what would make sense to me is to simply put the
> current download in that menu as well, and get rid of the need to have
> the download window entirely.
>
> The larger extension of that is that we want window switching to be
> about switching what you are doing, and not about polling for changes.
>
Owen, the message tray really rocks  but continuing the idea of
Johannes, What about the following usecase: Suppose you are reading a
paper (pdf, with evince), while reading this paper,
you open several other papers (references) for notations, basic stuff,
etc. If I understand correctly, to switch between these windows I need
to go through the overlay,which will show all applications opened and
making a lot of distraction.
In this use case, I would like to have an special overlay that allows
me to switch between different Evince windows (not all the windows
open in my desktop), since it is much easy to go through these to find
out the reference I want.
Currently, this can be done in Exposé and compiz with a hot corner...
to do this in gnome-shell, just seems too slow.  More generally, it
would be nice to be able to group windows or applications (and even
use Zeitgeist approach to do these groups, so you have an overlay with
less windows that can be more easily visualised)

At the Zeitgeist hackfest we designed a bar which pops down at the top of the screen and shows recent documents. [1] Assuming that I understand the concept of activities, that bat could serve (with a few modifications) as a replacement for the window list. Here's how it would work:
1. Instead of showing all recent documents, the bar would show recent documents which are related to the currently open documents. For example, if I have a pdf file open then the bar would show all of the other reference papers whether they're still open or not.

2. Each activity could show it's own bar.

3. The bar could be hidden by default or it could have a minimized view - something like the windowlist - that would show the documents. (Again, even if they're not open.)

4. When I use the term "Documents" that doesn't need to refer only to documents. When applicable, an application or even a window could be considered a document.

For example, most games don't open any documents so we can just show the game as a document-like item. (Which can form part of an activity.)

It might also make sense to show each Firefox window as one document so that the list of documents doesn't get overfilled with each tab that the user has open in Firefox. (If people learn to group related tabs into one Firefox window then that could work very well.)

5. In Zeitgeist, a document doesn't need to refer to a file on your computer. For example, it can also refer to tomboy notes and websites. In the future, we're going to even include Google Documents, Flickr pictures, and Delicious Bookmarks in our document database. All of these can appear in the same documents bar taking activities (collections of related documents, if I understand correctly) to a whole new level of usability.

A few caveats:
1. Zeitgeist's support for determining which documents are relevant to one another is still experimental and hasn't yet had a stable release.

2. We figure out which documents relate to one another (in the shell's terminology: which documents form an activity) based on their usage. (E.g. was one document opened while another document was open? Did the user switch often between one document and the other?) This means that there's no way of immediately telling what activity a new document belongs to when it's opened for the first time. To solve this, we can show the document in all of activity bars until we can determine which one it belongs in.

-Natan

[1] http://natanyellin.com/2009/11/12/zeitgeist-hackfest-user-experience-team/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]