At the New York summit Nat brought up collaboration repeatedly, and collaboration is the theme of the bounty contest.
A couple of flash demos: Kubi (skip the boring intro) and Groove (hope you can survive the horrible music). Slashdot also just posted this interview about IM which is related.
Kubi and Groove have the idea of project teams that share resources and collaboration forums, something I didn't notice in the bounty projects. What if we had a platform library that exposed your project teams. Teams would be made up of people in your contacts database. Then your IM client, Evolution, office apps, shared whiteboard app, panel applets, etc. could all take advantage of this team information. Perhaps there's some concept of "project you're currently working on" and information relevant to that project would appear - recently-used files, bookmarks, IM presence of team members, related email. Perhaps the active project is autoswitched if you open a document or mail related to a particular project, even. Somewhat dashboard-like in effect.
Here's another angle to think about it: what if each mailing list you're on had associated chat channel, whiteboard(s), files, calendar, and so forth. So the GNOME release team would be a project, for example. To have a meeting, the team members just make release team their active project, and they suddenly see a list of other present project members in their panel, have a chat window open, have the release schedule calendar open, have a shared whiteboard.
Better - what if the active project is per-workspace, so you can have more than one at a time. Or what if we autocreated a workspace for each active project, perhaps even replacing the idea of a workspace with the idea of a project? The advantage of a project over a workspace is that a project has a name and saved state (apps that are open, documents that are related, etc.) and can be activated or hibernated. We could also allow scratch projects with only one member (for that extra workspace full of random clutter).
Maybe that's not the right approach, but the point is we could probably do cool stuff by giving the desktop the concept of a project team.
A hard problem is how to make it easy for anyone (even Windows users) to join a project. One approach is to have a special Windows client. Another might be to use standards such as webdav or ical to put information at URLs, and then email/IM the links to Windows users. Another might be to have a server that exposed a web-based interface to the project data.
A much simpler task than this grandiose projects plan - we were wondering at the NY summit why nobody has implemented a shared whiteboard app. Seems like it'd be pretty easy, perhaps using Jabber/XMPP.
Just for Jeff, improved blame assignment for memory hogging.
Screenshots of the compositing manager prototype, also demoed live at the desktop conference yesterday.
Fedora Core 1 is out (release notes), and it rocks:
Slashdot readers... wow. Get your clues here:
Does "open source community" mean the Slashdot horde and their PC views, or the contributors who are building and supporting open source software? People use the term without getting this distinction clear in their minds.
The freedesktop.org X hacking is low-profile unstableware at the moment, but one particular proposal interests me the most. Here is how I understand it, I'll probably get it wrong:
The idea is to make the X server model-view. The server stores a tree of windows as it does now. However, unlike today, it keeps the full contents of each mapped window in memory at all times. For each window, the default view copies the window's contents over the contents of the parent window. This results in the same user-visible display you have today - but you could implement alpha blended windows by alpha compositing rather than copying each window into its parent, since we now have the parent window's contents.
To this we add the ability for a "compositing manager" to replace the default view for a given window, using the aXe and XDamage extensions. The window manager might be the compositing manager for toplevel windows, for example.
If a window has a compositing manager, it will not be composited into its parent automatically; the window is invisible until the compositing manager does something. An external compositing manager could emulate the default built-in compositing manager by using XCopyArea() (or alpha-aware equivalent) to copy windows into their parents.
However, a more exciting compositing manager might apply embellishments/transformations to the window contents prior to drawing them, possibly drawing them using an API such as OpenGL. For example, you could add drop shadows. Or you could do effects similar to fast user switching or Expose. Or you could double-buffer the entire screen as a whole making workspace-switching, opaque resize, and other tasks flicker free. The compositing manager is rendering a scene in which the window contents are one element, so the possibilities are endless.
Note that the window contents stay entirely on the server side, the compositing manager uses regular X protocol requests to manipulate them.
Apps other than the single compositing manager can also use the damage extension; possible applications include VNC (desktop sharing), magnifiers, pagers with thumbnailing, and so forth. The compositing manager is a special kind of view in that it disables the default paint of the window to its parent, and is thus responsible for replacing that default paint. But there can be any number of extra views of a window.
There are a lot of little complexities and open questions here, but the idea is pretty interesting. I'm waiting for something I can try out to appear in jhbuild so I can make metacity super-leet.
