(sorry if there's typo's--cranking these out as fast as I can)





Mattias Clasen talked about the plans for intentionally breaking the GTK API for 3.0 in order to make it possible to achieve new features: XInput2, the drawing API, and changing theme engines without breaking applications. Emmanuaele Bassi jumped in to help Mattias Clasen with explanations. A goal is to make it harder for people to do deep hacks like the current string of abusive theme engines that will break from release to release and provide a feature-rich foundation for doing work correctly upstream.



The discussion moved on to client-side-decorations with Cody Russell which are already being developed on a side-branch. The work has a goal of being merged for GTK 3. This will enable GTK-support for things like Google Chrome's tab-in-window decorator and (finally!) GTK rendering the theme rather than being drawn by the window manager.

Cody said that he has be communicating with Trolltech to ensure that Qt does it in a sufficiently similar way in Qt that there won't be compatibility issues between Qt and GTK applications that provide their own CSD.

The issue was raise of what happens when an application freezes--how do you close it if the decoration is frozen in the same thread? Cody said that some discussion about extending the EHWM spec. to specify the area of the window where the close button is so that even when the application is locked, it's still click-able.

Another issue was raise regarding resizing the windows: there's a "jarring" experience in which the WM performs a resize of the buffer and then GTK CSD lags behind before the border is redraw to the size of the new edge. A solution would be to handle resize ourselves.

The rest of the discussion revolved around various use-cases and a discussion for application-specific API's for CSD: how to provide API's for a status bar at the bottom of the window that is drawn by CSD and provides the drag handle that is--perhaps--hidden on a netbook when maximized. Also, themes that attempt to make the transition from the toolkit to the border "borderless" may want to make regions of the menu area cause window dragging.

A question was asked about Glib 3.0. No plans are in the cards for Glib 3; there could be some fundamental design problems addressed but there doesn't seem to be anyone asking for it.

The discussion transitioned to performance with regard to animations and whether GTK could be made to provide high performance animations. There was some thinking that it's possible to extend GTK but the challenges that have been met and overcome in Clutter would have to be completely redone for GTK and it would be non-trivial.

The discussion opened on API additions wanted for Clutter 1.2. Emmanuele listed the proposed new features on the chalk-board (which are all tagged in the bugzilla). Texture atlasing is a major new user-visible feature; this also brings a unified texture cache. Layout management is another feature programmers will want. Then, the floor was opened to other topics.

On the topic of input methods, Emmanuele is thinking of adding a modules plug-in architecture similar to the one used by GIO: API stubs that can be implemented in inherited classes. This would allow pretty much any functionality added via GtkModules to be reimplemented to ClutterModules.

There was a question about improving the performance with regard to only uploading changed sections of a texture: when the Evolution throbber is running, there's no reason to upload the entire window again. There's FBO-related (frame buffer objects) work on-going to make this more efficient and work correctly but there's no time line.

The VSync issue was raised: getting VSync to work correctly on top of a GL window manager on top of buggy hardware is a really hard problem to solve. LPC had a side-track in which this issue was discussed but those familiar with the discussion have the impression that the outcome (none of them were there) was not conclusive. The problem lies deep in the hardware drivers and sometimes the hardware itself.

A question was asked about the performance of glReadPixels (). Currently, Clutter uses a back-buffer to paint every actor a different color, glreadpixels() is used on the coordinates of the click, and the actor that was clicked is determined via the color that returns. There are three on-going separate ideas about how to do this differently, more efficiently, or just generally come at it from a different direction entirely (for example, non-rectangular, masked click regions). Look for more on this in the future.

The rest of the discussion revolved around defining the boundary between GTK and Clutter and how to articulate that to developers. There was a lot of lively discussion about what applications are well suited to each environment and a third class of applications that use GTK as a wrapper for menus and then contain a window region where "awesome stuff happens" (Clutter embedded). There was some agreement--looking at Apple as an example--that having two toolkits which specifically target a different kind of application with full support from Gnome wouldn't necessarily be a bad thing. In fact, having a usability guide for each, API references and programming guides for each, and reusing code for each where possible could provide a rich, diverse platform where any type of application is possible--and they fit together.

The session began with demo of the "usability kit" which was developed by Máirín Duffy and Ray Strode which records the keyboard, screen, and the user's face. The box contains a DVR-style device which records all four video inputs. It's using embedded Linux. Total cost of all hardware including VGA scan converter: $800.

A set of tasks are given by the test giver to be accomplish tester. The analysis is done after-the-fact where she fills in the user's behavior when given the task to complete. The video provides actual documentation between the lag of a user click and the responsiveness of the UI (especially helpful on a web site design).

She tests a wide range of users: developers and regular users.

Máirín recommends narrowing the scope down to a very specific set of tasks. Don't just say, "I'm going to test GNOME." Narrow it down to "File Management" and then come up with a list of tasks related to that and measure those.

Ray finished the session by showing how they use gstreamer to stitch the four separate video feeds in to a single video.

The floor was opened to discussion on how to do constructive user-army sourcing of input in a way that is useful for improving usability.

Jon McCann ran the Shell design session as a BOF discussion. He began with a straight forward introduction to where the Shell stands today comparing it to the usability hackfest exactly one year ago where GNOME Shell was born. An amazing amount of progress has been made but some major things still remain. (More on that later.) Fortunately, Red Hat decided to fund work on the Shell full-time so a lot of progress is being made, quickly.



Jon focused on the Shell UI as it stands today: the top bar is redesigned. The right-hand side is session-oriented actions: things that apply to the entire session. For example, your presence, log-in-and-out, and messaging. The notification tray is staying but a new messaging API is coming (more on that later.) In the center is the clock and date widget: it's needed and always changing. They wanted to balance the weight of the things in the bar to provide an even amount of content across the bar. Moving from right-to-left, the current application with focus is shown. In the future, a new API will be added to allow application level actions: Quit, Preferences, New Window, etc. Finally, the "Activities" menu is in the upper left (and is a hotspot) which activates the overview mode.

The overview mode grants a workspace layout view similar to Exposé. An important point is that workspaces are not forced on the users but they are immediately accessible should they choose to use them: the default workspace count is one. Jon gave the example of usability studies where users hit the "Show Desktop" button or the Workspace Switcher button, all their windows vanish, and then they panic. That can't happen in this design: when they return to the overview, everything is there.

The left-hand pane in the overview displays a search box, your list of favorite and all applications, recent documents and bookmarked places (from Nautilus/GIO).

Colin Walters jumped in to add that a central theme is that the new UI is application-based. The application title in the top bar is part of this but it runs deeper: the UI can request a new window from any application by calling the binary again. Applications that don't use some variant of libunique may launch a second instance. A short-term solution to that would to have applications that support a libunique-style application management approach to indicate that is so in their .desktop file. This difference also extends in to the new Alt-Tab interface which reflects applications in the top level view and, optionally, if more windows are present, an extended view of the individual windows grouped underneath the application icon. Mouse navigation is also possible in the Alt-Tab UI, now. Mouse wheel gives users who prefer a window-based approach, can now flip through windows rather than applications. A lot of insider tips are up at http://live.gnome.org/GnomeShell/CheatSheet; enabling expert-keyboard navigation is a major objective.

The floor was opened to discussion on design ideas. An issue was raised about showing the user the application window on the workspace they're on when clicking its icon in the shell--this will be fixed. Another issue was raised about allowing users that love to have tons of application launchers. The application well (the area where favorite and running apps. icons live) will accommodate a number of favorites and is still a little in flux but this use-case will be handled.

A large discussion centered around the Session menu (where your name is). There hasn't been a lot of attention paid to this menu yet but a central theme is that this menu should contain everything related to your session (like logging in and out; suspending), those things that are user-specific (like Preferences) and your presence (here, away, do not disturb, etc.). A tangential issue is making it clear that this is even a menu, in the first place. Owen threw out one proposed solution: a help bubble on first login that says "Click here to set your name."

Search is something of an open question at this point. Right now the list of items searched is menus, recent docs. and places. There's a desire to integrate with Tracker but it's still an open-ended issue. Storing other meta-data there would be a win: click frequency, for instance.

(a short break was taken)

A major objective that is just beginning is messaging: everyone is tired of getting their focus stolen by chat, SELinux, etc. Canonical deserves credit for trying to solve this in GNOME 2. Borrowing from that, the new design is inspired by this earlier work.

In the lower right hand-corner, a message queue will be displayed with things waiting for your attention: chat applications, mail notification, system warnings and music players. A critical difference will be that acknowledging receipt of a message is not the only way to get rid of it: a "message" can be suppressed temporarily without discarding it. To obtain the list of pending messages needing your attention, you can move your mouse to the lower right corner to have the message queue slide in. Newly arrive notifications will display for a short moment by sliding up from the bottom to display their message in a single line of text, remain for three seconds, and then slide out.

Chat apps. will be able to provide a simple notification of the message with a simple reply window for the rapid-style interruption allowing a user to immediately return to their primary focus. More involved chat will continue to be done in the IM client itself, for now.

Robert McQueen, who works on Telepathy, jumped in to say that most of the plumbing from the IM side is ready and is mostly in GNOME 2.28. Jon said that he'd like the ability to access the chat history in telepathy to get context.

A discussion about how to go about making this happen ensued. For example, should applications draw the tray item or respond to an API call when clicked? It's not clear at this point but there will be a libnotify compatibility layer for support of legacy applications. Unfortunately there really can't be a way to prevent people from abusing this message queue: applications that do would need to be encouraged to behave better.

Jon stated that he doesn't see that this message area would ever act as the primary interaction UI for an application: it's just a place for a quick reply or dismissal: not intended to be a primary UI.

There was a discussion about how the Empathy "Buddy List" fits in to this world if there is no notification icon, only messages in the message try. A "People Panel" is one proposed idea: integration of all applications with a concept of Contacts that allows you to initiate any communication via any method supported by that contact: chat, phone, email, etc. This is a very rough idea at this point, though. The inspiration for this approach comes from Moblin.

We ran out of time but there are two more GNOME Shell sessions scheduled.

Marina Zhurakhinskaya from Red Hat ran the session. In 2006, a Google-supported, 3-slot version of Summer of Code which was exclusively run for women. The Board would like to repeat that using Gnome Foundation funds. The first task is to contact the women who participated in the previous program and get an idea about where they stand today with regard to open source involvement.

There's a perception that, generally, the best way that these programs work is to select participants that already contribute in some regard. This is a challenge because there aren't a lot of women in GNOME today.

The second task is development of better introductory materials for both GSoC and Women's Outreach; there was a feeling from earlier meetings that there should be resources for the student that the mentor should go over: a list of aspects to the GNOME community that the mentor should introduce the student to: IRC, Planet GNOME, the social side of things. Also, the technical documents; not making it a scavenger hunt for the documents that they will need to accomplish their goal.

Third, proactively finding students by contacting universities and asking: "Do you have students that would fit this Women Outreach program?" This can make a huge difference in the level of participation.

Finally, finding mentors and working with them before the program starts is another focus area. (Marina asked that I link to the page where you can sign up as a possible mentor: http://live.gnome.org/GnomeWomen/OutreachProgram)

Marina then gave a summary of the FSF Women's Caucus. A summary is here: http://groups.fsf.org/wiki/Womenscaucus/9.19.2009

Then the floor was opened to discussion.

There was a question about having all module maintainers make an extra vigilant effort to to include women. It was pointed out that this can go too far: putting women on the spot unintentionally. It was agreed that this is a fine line to walk.

An issue was raised that we are generally, regardless of gender, very bad about helping new contributors. It's too hard to hand-hold the new contributor with no experience--most of us don't have the time. Owen's team working on GNOME Shell was pointed to as an example of a module doing an excellent job of to giving everyone who comes in to the IRC channel as much information as they can reasonably provide. A proposed solution that everyone agreed on was to revive GNOME Love--everyone remembered this being largely a success until the people (or person) providing the man-power could no longer run it.

The conversation switched then to marketing. A proposal for an effort to get more Windows to GNOME conversions was seeded as the starting point. There was some disagreement about whether GNOME should even be brought up in such a conversation with a point to the new Google "What is a web browser?" video that was published last week. It was pointed out that 5/6 of the most popular distro's give you GNOME by default so most people would have no idea that they're using GNOME, having not selected it.

The discussion got very lively at this point transitioning between many different tangential topics. There was some agreement that advertising is only a tiny portion of marketing: listening to users and implementing what they want is a huge part of marketing. It was pointed out that many people are now Tweeting their frustrations so we can mine social networks for "hot spots" of usability problems. And in some cases it may be good to engage the user directly and help them solve their issue.

There was disagreement about which message to emphasize in advertising: cool stuff you can do with free software or the freedom aspect, itself. The iPhone commercials were raised as a good example of showing off cool stuff that makes people want to have the product. This tangent was tabled until Monday but there appeared to be agreement that short videos would be better than putting up introductory documents.

We returned to the theme of trying to get more users and there was agreement that it's a very hard task to accomplish. A point was raised that, like buyers of hybrid cars, a "this is good for the world" aspect can be played on a portion of the population. There was agreement that this would work for some but not all audiences.

We ran out of time so the discussion will resume on Monday.