Brainstorming quick fixes for 2.28

[Owen Taylor <otaylor redhat com>]

Right now I'm planning to call next Friday's releases 
"GNOME Shell 2.28.0"; it won't be a stable release in any normal sense,
but is meant to be a bit of a fixed point. Something people can try out
and 

I sat down this afternoon with some of the other people working on GNOME
Shell in the office here this afternoon to try and do some brainstorming
on quick fixes we could do in a few days to try and smooth some of the
worst rough spots in the user interface.

The list we came up was a bit long... [what I meant to be a 20 minute
meeting turned into a 2 hour meeting], so we won't get to all of them
(at least without help!), but everything is individually quite
manageable and some pretty close to trivial.

Any mini-feature that's going to get in will have to be in by next
Wednesday, and we'll spend the last couple of days in pure bug fix.

* A fix for windows with 'needs-attention' set giving no indication
  at all that they are present. Quick design - if a window is 
  needs attention, show a small icon for the application as if it
  was in the notification area (to the left of all the system 
  icons), and make it glow and/or pulse. The same glow/pulse should
  be used for the icon in the Applications Well.

  We should try to detect when that application already has a status
  icon in the notification area, and omit the extra icon in this case
  (just assume that the application is blinking its icon.)

* Add a quick calendar popdown to the clock - it should look like

   <|  Sep 24 2009   |>

    Su Mo Tu We Th Fr Sa
          1  2  3  4  5
    6  7  8  9 10 11 12
   13 14 15 16 17 18 19
   20 21 22 23 24 25 26
   27 28 29 30

  Could just use GtkCalendar for this, but it's going to look better
  and if we rewrite it as Shell Chrome and it shouldn't take too long
  to do that.

* Continued improvements to the new Alt-Tab - Jon McCann is going to
  play around with it some as soon as it finishes landing and write up
  a list of revisions.

* Go back from "Browse" to "More" as the text for viewing more
  applications and documents. Hopefully this will be more manageable
  for translation.

* Remove icons from the categories in Applications browse

* Put a small gap between "Frequent" and the other 
  categories in Applications browse.

* Do something about paging control overflow in Documents Browse when
  you have very many pages. (Just hard-limit to 200 documents.
  Land the NBTK branch with scrolling and get rid of paging.
  RainCT's patch from bug 587549. Blocker on the NBTK branch
  landing is figuring out if to rename the forked widgets, and to
  what namespace)

* Insert date headers into Documents Browse (Today/Yesterday/Tue/Mon/
  Last Week) to make it not so much a gigantic undifferentiated list)

* When searching on applications, match on *menu* category as well.
  (This is pretty easy. Matching on the raw categories from the
  desktop file is hard without libgmenu patches)

* Highlight the matched text in the application description, and
  if the application description is longer than the space we have
  available, make sure to show the portion with the match. 
  (Dislaying matched portion; the simple cheat is just to pick between
  "start" and "end" ellipsize modes depending on where the match
  is in the string.)

* Integrate frequent applications into the application well. Quick spec
  is:

   * Start off with one row (probably 4 apps) of apps favorited as
     a GConf preference; user can add/remove.
   * After showing favorite apps, another full row is filled with
     the top frequent apps.
   * Non-favorite-frequent running apps are shown after that, but
     without a line break

* Add favorite/unfavorite to the app menu (Always? just if triggered
  by right click?)

* On small wide-screens (like netbooks), change the dash to screen
  width from 1/5 to to 1/4th. 1/5th of 1024 pixels is just not enough
  space.

* Remove the close animation; the tv-turning-off thing is just weird.

Also two performance issues:

* Continue working on search performance. Make sure that we have no
  IO going on during typing.

* Investigate why the gnome-shell process quickly runs up to half
  a gig of memory on Jon McCann's 64-bit machine.

I'm probably forgetting a few things so Marina/Colin/Jon may want to
jump with additions.

- Owen