People in Attendance:

• TravisReitter

• DavidTrowbridge

• PatrickWagstrom

• CoreyBurger

• TomHinkle

While this session was ostensibly focused on Gimmie, in reality it ended up focusing on the task oriented desktop and the need for a library to help provide context information for such a dekstop.

1. Task-oriented Desktop

• we're really only working on a single task at a time, but we may have multiple tasks related. ie. evolution may only show you emails related to the task that we're working on at the time. pick a task, every window and program is also in that task we're quite forgettable and distractable. we may be programming and decide to check our email which becomes distracting. we may be in one desktop and have open office open in another and wonder why our application didn't show up.

conceptual tasks:

• school work
• programming work
• waste time

Design Goals

• Tasks group apps into named tasks (like "Grading papers" "Hacking on Gimmie" "Wasting time")
• Windows "painlessly" grouped via:
  • All launched apps (all their windows/dialogs) are assigned that the current task
  • The main window of each app will get a pull-down menu (in the titlebar, or in the app icon menu) to assign it to a task (or assign it to multiple - temporary hack)
• Selecting a task hides apps from all other tasks to let you focus on Getting Things Done
• Apps do not know (or care) about which task they're a part of
• Main task actions:
  • New Task (provide task name)
  • Open Task (open saved task, restoring app state, like window dimensions and locations)
  • Close Task (Close all apps, forget about task; or Save state of all apps within a task, to open it later

A mockup is worth 1,000 lines of code

Expanded view of all tasks (Window selector applet implementation - not how it would look in actual practice):

How the above setup would look like in real use:

changing between tasks

do we want a hot key system? menus?

possible idea from Cory:

• some sort of cairo dragging setup

Applications that use tabs pose a particular problem as we may have different tasks operating in the same application, just in different tasks. For example, in Firefox we may have multiple web pages open for various tasks (work, wasting time, etc). To get at this information and to create a true task desktop, we'll need to have a method to interact with just the tabs of interest.

2. App/Document (Meta)Data Passing (to Gimmie)

Problem:

• Gimmie currently has to do a lot of hacks to get information from apps (Gimmie can only provide information about apps opened through Gimmie)

Proposal:

• New lib for apps to expose information to Gimmie (and other apps that are interested)
  • includes "live document metadata" - like the a current thumbnail of a Gimp document, rather than the thumbnail of its last save)
  • If an app isn't running, there needs to be an alternate way to expose relevant data (without launching the app)
  • We'll have to write patches for other apps (at least at first) to push their "live data" out to apps asking for it (Gimmie, others)
  • the library would allow other applications to publish information on entities that may not be a single file. For example, the Gourmet recipe manager uses a single database, but may contain multiple recipes. This would allow publication of what recipes are currently open.

How do we (currently) find out what things are open

applications are easy

documents are okay if we open them through gimmie

people it knows about through the GAIM dbus interface (which of course has its own advantages and disadvantages)

TODO (Actionable Items)

1. Application Data Lib
   1. Order the list of objects in order of implementation (punt hard stuff to the future)
   2. start with a general hack
      1. documents
      2. images/videos/ascii/unicode
      3. web pages (generic)
      4. arbitricious, app-formattable data structures
2. Fix gimmie notification area bug
3. Tasks
   1. Window switcher applet/metacity implementation
      1. window switcher mods
      2. metacity titlebar menus
      3. make minimizing physically obvious (like apple's genie in a bottle effect)
      4. modify tasklist applet to lump tasks into grayed out entries
      5. some applications may want to be across multiple tasks
   2. Gimmie implementation
      1. tasks selection (selects which set of apps)
      2. add physical metaphors for minimization

Long Term Things

• integrate with tasks with window manager to do some funky aiglx stuff to windows not in the current task
• working closer with the tasks and the virtual desktops -- automatically creating a desktop for new groups of tasks

The thought on these is that instead of the current desktop metaphor which can confuse some folks (watch my grandma freak because clicking on the workspace applet crashes everything), we have each task create a dynamic desktop. Thus, for the user who is oblivious to our task setup, it's just like having a single desktop environment. But for the advanced or busy user, with many tasks running, these new desktops will be created as they go, and destroyed as tasks are finished.

Related Work

NigelTao: I pretty much work this way already, with different workspaces being different tasks. Over the course of my day's work, the number of workspaces that I have can start at 1, grow to half a dozen or more, and collapse back to two or three by the end of the day. I use Superswitcher (SVN repo, screenshot) to easily create (and close) workspaces on demand - it's a two-key combo (Super-Insert to create, Super-Delete to close an empty workspace) rather than e.g. right-click on the workspace applet -> Preferences -> etcetera. Two things I don't do are (1) a specialized window selector applet (I have a centered popup window, with drag-and-droppiness of windows between workspaces) and (2) name my workspaces, but both of these would be straightforward to add to future superswitcher releases.

MartinSoto: Any thoughts about making tasks persistent? These days, for example, I'm hacking a Free Software project, working on the software for my PhD, participating in three different research/consulting projects at work, and writing a research paper. Of course, I also find some time to pursue my intellectual interests, (as you call them ) like reading Slashdot, a few assorted blogs and blog aggregators, and some news sites. Of course, that's a lot of stuff to do at the same time, and even in a single day, I may only get to work on only a few of those tasks. For this reason, it would be great if I could freeze a task when I can't work on it anymore. Freezing the task would mean that all documents in it get closed, but their state and configuration get saved for future use. This way, when I find time to work on the task again, I just unfreeze it and continue working. I know this is related to the current session management discussion, and, actually, I think persistent tasks could be a nice way to implement powerful yet usable session management.

PatrickWagstrom: We discussed making tasks persistent, this requires a lot finagling on the part of the applications to get working properly. One application that does show a good example of this is the new Firefox betas (Bon Echo) -- but that's mainly if the app crashes. From our perspective, our thought was that we'd just hide the elements for different tasks when you're not working on that task. Of course, this doesn't do much if you're going to be shutting down your computer between uses. I'm not sure how much of this session management stuff has been addressed at the summit.

TravisReitter: marino pointed out Dashboard Cluepackets, which sound much like the data hinting library.

Comments

JohnNilsson: This projekt would prbably benefit from some of the ideas in this book: Getting Things Done: The Art of Stress-Free Productivity. If you haven't seen this allready, I strongly urge you to take a peak. This seems like the perfekt opportunity to streamline the system according to the guidelines in this book.