The GNOME 3.0 launch theme
The morning began with a hammering out of the GNOME 3.0 launch theme and marketing approach; we brainstormed for two hours. This discussion largely built on the discussion that we had the day before but, this time, we came to some final conclusions.
First, we agreed upon the themes--the Shell, the search work, the new levels of cross-application integration--all substantially advance the release team's primary point of the 3.0 release: a better user experience. We enumerated several points that are critically important to cover in any marketing effort. I will return to those in a moment.
Second, working backwards from the list of final results that we wanted to achieve, we turned our attention to language that we might use to explain these concepts to end users (the target of this hackfest). We came up with a large, nebulous list of concepts that we felt would appeal to a potential slightly interested, slightly technical conference attendee (our litmus test).
Third, we stepped even further back from these concepts and tried to hammer them in to a single, coherent over-arching theme for the GNOME 3.0 release marketing effort.
We laughed; we cried. We bounced on giant bouncy balls in the Google color scheme (thanks for hosting Google!) and spun around staring at Chicago skyscrapers in three cardinal directions grasping for inspiration. We buried our heads in similarly multi-colored beanbag chairs in frustration. We stared at the white-board in quiet contemplation for long minutes in silence trying to coax out the essential answer to the giant, nebulous problem ahead of us. End the end, it just came to us--everyone immediately liked it and agreed. Suddenly, we had our theme.
In the coming weeks, the marketing team will write up a formal announcement and prepare some preliminary art. Vinicius already had some great looking artwork done before the end of the day. So, I'm excited about this marketing effort. Paul, in his excitement, already began scheming all kinds of way to use our theme. I think that GNOME 3.0 is be going to be fantastic and so is its marketing effort.
The 3.0 marketing end game
From here on in, GNOME 3.0 is all that we will talk about with regard to marketing. 2.30 will merely be passively marketed. We agreed on some major assets that we want to develop for the release of 3.0.
For distributions, production of high-quality, templated marketing assets begins in February, seven months before 3.0 is released. GNOME will provide video, artwork, flier, brochure and sticker templates that are optimized for a prominent distribution logo with a small with GNOME 3
aside from the distributor's own trademark. In the case of the videos, the lead-in and lead-out will have a large area in the center for the distributor's logo.
In this way, we make it easy for distributors to help get the message out about why the user experience is better than it has ever been before.
For users and those whom interact with GNOME directly or via viral sources (YouTube, Facebook, review sites), the GNOME marketing assets will be the same as those provided to the distributors but with a distribution neutral lead-in and lead-out. We--after some serious thinking about how to deploy this correctly without nagging--will encourage that videos that describe useful new features be included in the default desktop installs (perhaps as documentation assets).
For conference speakers and attendees, we, in the later half of the day, worked on finishing up our conference assets by refreshing our presentation slides (we did the brochure, FAQ and talking points on Day 1). They are now small sets of 5-minute topics that can be plugged together to form an hour long talk. (We are finishing these up on the marketing list.)
The 3.0 videos for the attention deficit
The videos that begin being filmed in March are inspired by the Google Navigation feature videos: http://www.google.com/mobile/navigation/
The work to do
We have at least two more marketing hackfests planned because there is just so much more work left to get done. Especially in the video production and artwork side of things. Please volunteer.
If you code, you're marketing; take it one more step
When we listen to our users and we give people what they want, we are marketing. When we blog about our accomplishments, we are marketing. We ask that every module maintainer go one step further and help the 3.0 marketing effort. Tell us early what your visible new features are. Make a screen cast early; it might become a professionally produced video asset. Answer questions about 3.0 in a non-confrontational, informative manner on technical blogs.
Whether this release will experience the "KDE 4.0 effect" depends on you understanding the awesomeness that is the new user experience and articulating that wherever you can.
Friends of GNOME, the other awesome
Stormy lead the discussion about what to do about promoting Friends of GNOME. It has been a massively successful program and she thought that it could do so much more. In the short-term, we want approximately 50 new subscribers by the end of the year. A thermometer
goal graphic has been developed and this will be deployed on Planet GNOME.
If you like hackfests, please give to and promote Friends of GNOME.
In the long term, after a hour of discussion, we devised a method by which we can help the release team achieve its goal of avoiding blessing modules as The One Official GNOME Version of X,
form high-value cross-promotional relationships with distributors, and promote Friends of GNOME--all in the same GNOME Goal which we, the marketing team, shall be proposing first to the release team and then to the entire project. I need to write some proof of concept code first, though. Much, much more on this later.
Thank you to Google and Novell
Google, thank you for hosting us; the food was great and the facility was just what we needed. Novell, thank you for helping with travel costs. Meeting face-to-face rocks.
So it turns out that this hackfest is not as conducive to the blog-by-blog as the Summit is. There was a lot of meandering discussion and, generally, very little boundary between one topic and the next. We constantly jumped between discussion and working.
The conference materials session review digressed to what language and ideas to use when discussing GNOME and GNOME 3.0 with the press and users. The finalization of the conference materials would be finished after this discussion. In order to reach agreement, Paul showed everyone the presentation that he's been giving to conferences about what GNOME 3.0 will be; with everyone up to date, we moved on a discussion about what the over-arching themes are. We referred to the release team's announcement about what GNOME 3.0 would be from April:
http://mail.gnome.org/archives/desktop-d
In that email, Vincent listed:
So, we the marketing team, are the third item on that list and it's our job to explain the first item. Earlier, we agreed that this two-day hackfest only focused on end users. With our primary objective set to marketing the "revamped user experience", we could make progress on the language of the conference materials: from this point forward all marketing effort is 100% on GNOME 3.0--GNOME 2.x is no longer a marketing focus. This synthesis unleashed a flood of productive idea-making.
The "talking points," "FAQ," and brochure content were completed with wide agreement on their content: a heavy emphasis on how GNOME is a vibrant community with information about what tangible results users can expect to receive when GNOME 3.0 is available.
There was wide ranging discussion about what GNOME 3.0 is and how much of a change it is. We talked with each other about what each of the proposed technologies will bring to the end user experience: tightly integrated search, application-oriented window management, dynamic workspace workflows, temporally oriented document location (Journal), interruption suppression (message tray), and user interface physicality (via window and Shell chrome animations). There was also agreement that aside from "3.0" technologies, there's a number of long-stewing features coming to fruition that can also be emphasized: Telepathy, for example.
There was an observation that we're achieving a new level of tight integration throughout the desktop environment. Think of IM notifications with rapid dismissal in the messaging tray in Shell. Or, think of Empathy sharing your Desktop with you friend via Telepathy without you needing to open a firewall port. Another example could be how both the Journal and Tracker technologies (potentially) tightly integrated with the Shell UI.
We pursued a long tangent about the UI change and how we need to sell that to our own community first and then end users. The menus-have-icons thread on d-d-l was discussed as an example of a way in which we can help. There's a feeling that this thread is only the tip of the iceberg and--that perhaps--showing people in a visual way--or at least explaining the decision on a marketing page--what the change achieves would be a good thing. This is an action item to be rapidly developed and put out up so that we can head-off the spatial Nautilus situation repeating itself.
We tabled the discussion of selling people on GNOME 3.0, specifically, until tomorrow.
We shifted our focus to improving our relationship with downstream marketing and branding. After much brainstorming, we all agreed that developing high quality, professional-looking, templated marketing assets would be a service that we could offer downstream to help us convey the message that GNOME is the upstream source of the UI experience. These templates (in the form of 30 second promo videos, release note snippets, brochures, and artwork) would have a place holder for the distro's logo with a smaller "with GNOME" logo beside it. In this way, we can provide manpower for downstream marketing effort and get our branding made more visible.
Continuing on the theme of distribution relationship building, we decided to explore a more informative About dialog policy. This policy was developed in length but must first be cleared by the release team. We will be proposing this idea to the release team and, if they don't think it's crazy, the wider GNOME community. If adopted, GNOME Marketing would establish robust branding and promotion cooperation with downstreams who are interested in having their distro's promoted in official GNOME press releases and marketing properties. More on this at a later time.
Over dinner, we focused on bringing more people in to the marketing team: pair with new members, how to talk to the press and write press releases, how to stay on message, raise funds, etc. We spoke at length about marketing videos for the GNOME 3.0 launch: production is to begin in May with preliminary work before that. (During dinner we also hammered out details of our upcoming proposal to the release team.)
The conference materials session review digressed to what language and ideas to use when discussing GNOME and GNOME 3.0 with the press and users. The finalization of the conference materials would be finished after this discussion. In order to reach agreement, Paul showed everyone the presentation that he's been giving to conferences about what GNOME 3.0 will be; with everyone up to date, we moved on a discussion about what the over-arching themes are. We referred to the release team's announcement about what GNOME 3.0 would be from April:
http://mail.gnome.org/archives/desktop-d
In that email, Vincent listed:
- Revamp our User Experience
- Streamlining of the Platform
- Promotion of GNOME
So, we the marketing team, are the third item on that list and it's our job to explain the first item. Earlier, we agreed that this two-day hackfest only focused on end users. With our primary objective set to marketing the "revamped user experience", we could make progress on the language of the conference materials: from this point forward all marketing effort is 100% on GNOME 3.0--GNOME 2.x is no longer a marketing focus. This synthesis unleashed a flood of productive idea-making.
The "talking points," "FAQ," and brochure content were completed with wide agreement on their content: a heavy emphasis on how GNOME is a vibrant community with information about what tangible results users can expect to receive when GNOME 3.0 is available.
There was wide ranging discussion about what GNOME 3.0 is and how much of a change it is. We talked with each other about what each of the proposed technologies will bring to the end user experience: tightly integrated search, application-oriented window management, dynamic workspace workflows, temporally oriented document location (Journal), interruption suppression (message tray), and user interface physicality (via window and Shell chrome animations). There was also agreement that aside from "3.0" technologies, there's a number of long-stewing features coming to fruition that can also be emphasized: Telepathy, for example.
There was an observation that we're achieving a new level of tight integration throughout the desktop environment. Think of IM notifications with rapid dismissal in the messaging tray in Shell. Or, think of Empathy sharing your Desktop with you friend via Telepathy without you needing to open a firewall port. Another example could be how both the Journal and Tracker technologies (potentially) tightly integrated with the Shell UI.
We pursued a long tangent about the UI change and how we need to sell that to our own community first and then end users. The menus-have-icons thread on d-d-l was discussed as an example of a way in which we can help. There's a feeling that this thread is only the tip of the iceberg and--that perhaps--showing people in a visual way--or at least explaining the decision on a marketing page--what the change achieves would be a good thing. This is an action item to be rapidly developed and put out up so that we can head-off the spatial Nautilus situation repeating itself.
We tabled the discussion of selling people on GNOME 3.0, specifically, until tomorrow.
We shifted our focus to improving our relationship with downstream marketing and branding. After much brainstorming, we all agreed that developing high quality, professional-looking, templated marketing assets would be a service that we could offer downstream to help us convey the message that GNOME is the upstream source of the UI experience. These templates (in the form of 30 second promo videos, release note snippets, brochures, and artwork) would have a place holder for the distro's logo with a smaller "with GNOME" logo beside it. In this way, we can provide manpower for downstream marketing effort and get our branding made more visible.
Continuing on the theme of distribution relationship building, we decided to explore a more informative About dialog policy. This policy was developed in length but must first be cleared by the release team. We will be proposing this idea to the release team and, if they don't think it's crazy, the wider GNOME community. If adopted, GNOME Marketing would establish robust branding and promotion cooperation with downstreams who are interested in having their distro's promoted in official GNOME press releases and marketing properties. More on this at a later time.
Over dinner, we focused on bringing more people in to the marketing team: pair with new members, how to talk to the press and write press releases, how to stay on message, raise funds, etc. We spoke at length about marketing videos for the GNOME 3.0 launch: production is to begin in May with preliminary work before that. (During dinner we also hammered out details of our upcoming proposal to the release team.)
Stormy updated everyone on the status of replacement of the conference box that was stolen. She gave a list of items that need to be created or procured.
Our agreed upon tasks was to develop FAQ for booth organizers, develop talking points for booth organizers, design brochures and handouts, design a banner, come up with a wishlist for the conference box.
(I will not be blogging the actual discussion of working sessions; the results should speak for themselves.)
Our agreed upon tasks was to develop FAQ for booth organizers, develop talking points for booth organizers, design brochures and handouts, design a banner, come up with a wishlist for the conference box.
(I will not be blogging the actual discussion of working sessions; the results should speak for themselves.)
We are assembled at Google Chicago to begin the Marketing Hackfest! Six of us are assembled so far and we're looking forward to being joined by another half-dozen, or so.
We will be tweeting and identic-ing all day and tomorrow as we proceed through our long list of discussion topics and working sessions.
Watch this space for the blog-by-blog.
Update: Before we began, we discussed our target audience--an overarching theme for the two-day hackfest.
Paul pulled opened the discussion by saying that for the next two day, he wanted to talk about end users. Stormy said that she wanted to make sure that we partner with downstream partners as well as go directly to end users; she was also concerned about focusing on either technical users or "all" users. There was agreement among everyone that we can target "all" users effectively.
We are not targeting developers for this two day hackfest.
Stormy pointed out that we haven't had success targeting office and business users. Only when the netbook market broke out, did we and our downstream partners get a lot of traction.
Shaun was worried about sending a message that we aren't good for office users in inadvertently. Paul and Stormy thought we could stay on message without giving people that impression.
Jason was concerned about not advertising for office and profession photography users when the software isn't there yet. There was agreement that those users would be at the outer edges of the bell curve.
Everyone agreed again that we would focus on home users for the two day session.
We will be tweeting and identic-ing all day and tomorrow as we proceed through our long list of discussion topics and working sessions.
Watch this space for the blog-by-blog.
Update: Before we began, we discussed our target audience--an overarching theme for the two-day hackfest.
Paul pulled opened the discussion by saying that for the next two day, he wanted to talk about end users. Stormy said that she wanted to make sure that we partner with downstream partners as well as go directly to end users; she was also concerned about focusing on either technical users or "all" users. There was agreement among everyone that we can target "all" users effectively.
We are not targeting developers for this two day hackfest.
Stormy pointed out that we haven't had success targeting office and business users. Only when the netbook market broke out, did we and our downstream partners get a lot of traction.
Shaun was worried about sending a message that we aren't good for office users in inadvertently. Paul and Stormy thought we could stay on message without giving people that impression.
Jason was concerned about not advertising for office and profession photography users when the software isn't there yet. There was agreement that those users would be at the outer edges of the bell curve.
Everyone agreed again that we would focus on home users for the two day session.
Because Planet is spam-filtering my posts, here are the blog posts by myself and others covering all the awesome that happened at the Summit:
- GTK 3.0 and CSD
- Clutter 1.2
- Usability Kit and follow up by Ray Strode
- GNOME Shell Design
- GNOME Women Outreach / Marketing
- Geolocation
- GObject Introspection
- Glib/DBUS and GSettings
- GNOME Shell getting involved, tech and Web Browser Integration
- Splinter and git bz
- Telepathy BOF at the Boston Summit
- Alberto Ruiz's summary of his hallway tracks
I missed National Coming Out Day in the U.S. (SJR reminded me). Some way that everyone can enjoy the celebration is to expand their musical horizons a little.
I ran an LGBT (lesbian, gay, bisexual, and transgender) radio show for five years, and, in that time, I came to appreciate that music made by queer artists taps in to visceral gender dynamics that other artists don't seem to be aware of. These themes speak to me and they may speak to you.
Sacha Sacket. I ran in to this guy when he was touring the country, living out of his car. He made a stop in KC and I swung by the little mini-concert on a college campus. My favorite album is Shadowed; the first track, The Prodigal, gives me chills. Cruel Attempt, reminds me what it's like to be on the receiving end of objectification: to be the chicken to someone else's hawk. Hallowed from Lovers & Leaders reminds me of the approval and mentorship that is sometimes terrifyingly absent in our lives when we're vulnerable.
A recent addition to my favorites list is a recent entrant to the world stage: Antony and The Johnsons. Much critical acclaim has been made of hernew album, I Am a Bird Now, and I can't disagree. It's stunning. The track that gets a lot of attention is For Today I am A Boy and deservedly so. But there are other gems here: Spiralling, with Antony's haunting voice, is affecting. Bird Gerhl is full of pain and hope.
The post brought to you in the spirit of Harvey Milk.
In other news, I made it back home from GNOME Boston Summit 2009 and I will be activating LightsOff by default and the merging the Gnibbles rewrite tomorrow.
I ran an LGBT (lesbian, gay, bisexual, and transgender) radio show for five years, and, in that time, I came to appreciate that music made by queer artists taps in to visceral gender dynamics that other artists don't seem to be aware of. These themes speak to me and they may speak to you.
Sacha Sacket. I ran in to this guy when he was touring the country, living out of his car. He made a stop in KC and I swung by the little mini-concert on a college campus. My favorite album is Shadowed; the first track, The Prodigal, gives me chills. Cruel Attempt, reminds me what it's like to be on the receiving end of objectification: to be the chicken to someone else's hawk. Hallowed from Lovers & Leaders reminds me of the approval and mentorship that is sometimes terrifyingly absent in our lives when we're vulnerable.
A recent addition to my favorites list is a recent entrant to the world stage: Antony and The Johnsons. Much critical acclaim has been made of her
The post brought to you in the spirit of Harvey Milk.
In other news, I made it back home from GNOME Boston Summit 2009 and I will be activating LightsOff by default and the merging the Gnibbles rewrite tomorrow.
Owen opened the session by demoing Splinter, the web UI for reviewing patches.
Owen went to Bugzilla, listed his open patches, opened the patch view, clicked a line of the patch, and added an annotation. The UI is intended to facilitate adding your own comments but also efficiently view other people's comments in-context.
It stores the results in a normal Bugzilla comment that's human readable but also parseable by the Bugzilla extension. While you are reviewing, it stores your work in DOM storage so that you don't lose it if your browser crashes.
Ryan Lortie said that this is totally awesome. Wide agreement. He also wondered if Owen intends to push it upstream. Owen replied that he doesn't intend to push it upstream but go about rather pushing it as an extension--especially to the Bugzillas he's forced to use.
Owen then switched to git bz, the git bridge to Bugzilla. This tool allows posting patches for review. It turned out that most people in the room had tried it and agreed it is awesome, so a demo was skipped. Owen wants to make it better at merging patches.
A side project that they were thinking of doing was creating a gnome-terminal plugin for a toolbar that displayed your git status, showing all branches and your status with regard to upstream.
Emmanuele was hoping for a branch-per-bug. Owen replied that Dan Williams was hoping for this, but this is hard because, for example, what happens when you `git bz pull` in this branch? Does it pull the current bug status?
Someone asked about pushing git bz upstream. Owen thought that this would never happen: git bz is in Python and upstream is C, Perl and lots of Shell.
And that's it for the Summit Sessions!
At this point, the rest of Summit is hacking with a Beer Summit at 8 PM. (Which I will not be giving the play-by-play of, hopefully. Okay, maybe on Twitter. Check out @gnomesummit!)
Owen went to Bugzilla, listed his open patches, opened the patch view, clicked a line of the patch, and added an annotation. The UI is intended to facilitate adding your own comments but also efficiently view other people's comments in-context.
It stores the results in a normal Bugzilla comment that's human readable but also parseable by the Bugzilla extension. While you are reviewing, it stores your work in DOM storage so that you don't lose it if your browser crashes.
Ryan Lortie said that this is totally awesome. Wide agreement. He also wondered if Owen intends to push it upstream. Owen replied that he doesn't intend to push it upstream but go about rather pushing it as an extension--especially to the Bugzillas he's forced to use.
Owen then switched to git bz, the git bridge to Bugzilla. This tool allows posting patches for review. It turned out that most people in the room had tried it and agreed it is awesome, so a demo was skipped. Owen wants to make it better at merging patches.
A side project that they were thinking of doing was creating a gnome-terminal plugin for a toolbar that displayed your git status, showing all branches and your status with regard to upstream.
Emmanuele was hoping for a branch-per-bug. Owen replied that Dan Williams was hoping for this, but this is hard because, for example, what happens when you `git bz pull` in this branch? Does it pull the current bug status?
Someone asked about pushing git bz upstream. Owen thought that this would never happen: git bz is in Python and upstream is C, Perl and lots of Shell.
And that's it for the Summit Sessions!
At this point, the rest of Summit is hacking with a Beer Summit at 8 PM. (Which I will not be giving the play-by-play of, hopefully. Okay, maybe on Twitter. Check out @gnomesummit!)
Owen Taylor opened the session and then ceded the floor to Colin Walters to follow up on a point he made in the GObject Introspection session. He showed the internals inside of Mutter and how they become accessible to GJS/Javascript inside the GNOME Shell plug-in for Mutter. He then opened the interactive JavaScript console inside GNOME Shell and showed squishing the windows via global.get_windows(). He also showed using Looking Glass tool to inspect the stage, get a reference the the JS object associated with an actor and then change its properties.
Owen took over and showed how easy it is to take the property you just changed, change it in the code on-disk and then type 'restart' to reload the shell with your new code.
Jon McCann reminded Owen that they just landed CSS. Owen showed changing the CSS file for the calendar widget and then restarting the shell. Someone asked about theming; it will be supported in the future. Another person wanted to change the code on disk and then have that immediately reflected in UI. That's not going to really be possible and the complaints associated with restart taking too long will be addressed by speeding this up dramatically. The speed-up needs to happen for login time, anyway.
Someone wanted to know about Shell's CSS implementation and how the names are done. Owen stated that they wanted to stay as close to the behavior that you expect on the web to make it easier for new people to develop. In that regard inheritance of CSS properties is also supported in the Shell Toolkit.
Jason asked about encouraging web developers to come and develop widgets in the Shell and the possibility of them bringing their bad development habits with them. Owen replied that he doesn't really envision Shell as an application platform but for those who want to develop widgets that problem can be addressed with code style guidelines.
Accessibility was wondered about. Owen said that they are still at the state of really figuring things out. There are some core things that need to be addressed like, generally, making Clutter accessible. Once that's there--and the toolkit layer is there--there's really not that much going on in the Shell that a11y would need to be implemented for. Colin mentioned that a new magnifier inside Shell was being implemented.
Owen showed off using other units in CSS: em units instead of px. This is fully supported.
Someone expressed concern about using two toolkits in the same UI. Owen replied that there's only one example of that right now, the click menu for the Session menu. There's a hope that everything will be based on ST, in the long-run. A tangent to this discussion was how the notification tray works: it's a composite of GtkEmbed/XEmbed. Someone asked about Pidgin: in older versions of Shell it would show a gray background. They work around this Pidgin bug by setting the static background color to black.
Shaun McCance asked about using Shell Toolkit outside of Shell. Owen replied that he doesn't want ST used outside of Shell and really doesn't want to maintain a toolkit. Plus, ST is mostly NBT from Moblin. Some things will move down the stack in to Clutter, like layouts. He envisions a good toolkit for everyone to use in the future but didn't know what that would look like; he then looked to Emmanuele from Intel.
Emmanuele said that NBT is very specific to their user-interface guidelines for Moblin. When they see something generic enough for everyone, they intend to move that in to Clutter. Generally though, Clutter is going to remain very generic and not become a full toolkit.
The conclusion to this tangent was that--for now--use a mix and mash of Clutter when it makes sense. And there was a recommendation to not try to take ST out of Shell.
Someone asked about "Show the Desktop". That elicited a slightly sheepish response: they don't really know what to do about it yet. Right now, it sucks. If you accidentally click on the desktop and press delete, you delete a file. There's some thinking that showing the desktop at all is a bad idea. So, more discussion about this will have to take place.
The focus switched to web browser integration. Jon McCann took over, a critical point was how to manage tabs in applications at the window manager level. There's some application API needed to make this happen. And one problem to solve is how to make grouping makes sense. For example, GMail and the rest of your browsing don't really make sense to have in the same top level window together. There was some back and forth between Colin, Jon, and Xan (from Epiphany/Webkit) about how to make this work right.
Jon is aware that this is all a little in flux. Right now, Firefox 4 is considering making a "Home" tab that has a "journal" of your web activities. How would this fit at the top level window manager? There needs to be a more expressive API than just simply "a tab". Xan stated we also need to also find a way to handle people like himself that have as many as 50 tabs open at once. Jon agreed but also pointed out that--perhaps--there needs to be support for single-instance tabs. For example, you wouldn't want more than one instance of GMail open. Emmanuele described how Moblin handles this. Based on this discussion, it sounded like some of this should be solved by the browser.
Xan wanted to be able to filter all tabs at the level of the Shell to show and allow to pick the a tab from the Shell workspace overlay. Some thinking was that GtkNotebook could communicate this to the Shell. Owen describe a tangent design in which the search bar allows you to search window titles. This is a very early idea and it might be good to pursue.
There was a question about using Search integration with Tracker in parallel to the desire to allow tabs to be searched. Owen and Colin seemed to think that taking Tracker integration to that level is probably not something that they want to do in the Shell UI but they do think it's worth exploring how applications should behave when search results are selected. For example, whether it launches a new tab or brings the tab to the front that's already open.
Owen listed his short list of things to work on: messaging tray, application browsing in the "More" menu, recent documents is not optimal, more people-based results, fly-over pop-ups for more information, the sidebar, the application menu (on the top bar) and extensions.
Shaun said that a big prerequisite for a 3.0 release would be good documentation.
There was a question about what would be needed for 3.0-readiness. Owen replied that he sees the things that are needed are the short-list above, docs, and a11y. He sees a rocking experience as a major factor.
There was a question about moving a subset of the most critical panel applets over to Shell. Owen and Colin see this as a multi-faceted problem. Things like Keyboard Layout applet need to be first-class citizens. On the other hand, Deskbar could be solved by making the search field extensible. Other plugins, like a stock ticker, need to be sidebar things.
Shaun asked about Tomboy. Owen said that Tomboy could use the application menu in the application well as the entry point to provide a custom menu specific to Tomboy. Tomboy could also provide a search extension to display its notes in the search results.
That's it for GNOME Shell sessions!
Ryan Lortie began the session by giving everyone an update on the hallway-track discussion regarding the availability of DBUS access inside Glib.
He began with a brief history of some precursors: gbus (from two different people), eggdbus, and now gdbus. There's a lot of problems with these versions including leaking implementation details through the API.
The first step to sanity and what was agreed upon was to merge GVariant in to Glib. GVariant provides support for DBUS's data types. Second, libgio will link to libdbus1, possibly via a GIO module extension point. Third, some of the best parts of gbus and gdbus will be picked and merged in to GIO.
There was a tangent about implementation details regarding which pieces of each of the DBUS binding precursors to take implementation ideas from. Another tangent shot off of this between Robert McQueen and Ryan Lortie regarding the features that would be needed to obsolete all of the custom DBUS solutions out there. (This lasted a very long time without much conclusion.)
A critical feature was requested by Colin and Ryan agreed: this new binding needs filtering and path registration.
Emmanuele pointed out that a tangent related to this work would be to put libunique in GIO on top of this new binding since many applications will want that feature, anyway. There was agreement that this was a good idea.
Ryan then demonstrated writing code using GVariant. Much happiness ensued.
Ryan then switched the session to GSettings. He said that there is a lot of excitement about GSettings: there's a desire to also add it to GIO after GVariant is merged. He began the GSettings discussion by going over the GSettings API. Some highlights included atomic changed signals for all settings changed at once, rather than getting a bunch of signals for each setting. There is not yet a filter function that would allow inverting a value coming back from GSettings. (For example, allowing you to show the opposite value in a bound UI widget.)
There was a question from Colin about whether it would prevent recursion: it does.
Then, Ryan showed an example Vala program using GSettings. Mandatory setings are supported--during the widget binding step, sensitivity will be set to off if the key is mandatory.
He demonstrated the schema format underlying GSettings: it's a simple format supporting inheritance with a simple plain text format.
A side question was about how Sabayon could support this. Ryan replied that the method would be to monitor the root of dconf for events and capture them there.
Ryan switched to demonstrating dconf to replace gconf. He went over the API as it stands currently; it's simple.
There was a question about the case where a user has an UI open when a lock gets activated by a system administrator. There's no support for the notifying the UI that the lock has been activated while it's open. A tanget spawned about how a user could get admin. privileges from the UI; Ryan will be adding PolKit support soon.
Someone asked about performance. Ryan said it's 10-50x faster than gconf on reads. Ryan discussed some of the implementation details that made writes high-performance, as well.
There was a question about synchronization of writes to avoid a race in a reading application. The dbus writer process uses fsync() a lot but you don't care because it's not blocking your application.
There was some concern about multiple users using the same home directory (a coffee shop, for example). Ryan didn't think this would be an issue but it doesn't make sense to do this anyway; he couldn't think of any application that repositioned a window based on notification that the state stored in gconf had changed. But, he recommended doing what others are doing: clone the pristine home directory on login.
Someone asked about doing regression tests of applications by setting the proxy settings in gconf/dconf without affecting the user session. Ryan suggested doing a custom GSettings plugin that redirected the requests to a temporarily database.
There was a tangent about allowing launching applications via a dbus call. There was some thinking that this could be a good idea but that some work would have to be done to make sure that launching the application the traditional way would have the same kind of interface.
Ryan described the plumbing of the default database. A question related to this topic was about how to do distro. packager overrides of upstream defaults. Ryan suggested modifying the schema via a package patch rather than having vendor-specific defaults databases on the system aside from upstream's default database.
He returned to the benchmarks they've run. Another big win is that dconf is only running during the writing process--even then, the memory consumption versus gconf is an order of magnitude smaller.
There was a worry expressed about NFS home directories. Ryan replied that there is a bug because of fsync() but he's working on it, actively. It's going to be hard to fix but he's committed to finding a solution.
He's going to be putting the documentation on library.gnome.org. There will be some documentation on how to do module migration in the future.
Finally, he wanted everyone to know that they are working on a gconf to dbus bridge. It runs some simple applications right now but there are some serious problems to solve. Help is needed especially with this part.
Colin Walters ran the session with a short introduction to what GOI is. He said that GObject was ripe for doing this to: the type system already had a lot of what was needed to reach the goal of making it a lot easier to script our C libraries. A few things were needed to get there, though, mostly annotations.
Colin demonstrated how to annotate your C libraries to make them accessible from GOI. This annotation data contains simple declarations of what, for example, containers are being passed around by your pointers and whether you, the consumer, need to unref. it when done. (Take ownership.)
When running the annotation parser, an XML file is written to a .gir; the gir is then compiled to a .typelib which is an efficient binary format containing the same information. These are the two parts work together to make a language binding work without any additional work on the part of the language binding.
GJS is already ready. PyBank is the GOI-based Python binding. It's fairly complete at this point--some call conventions had to be worked out for compatibility. Colin is of the opinion that the legacy bindings shouldn't be replaced: where the work was done by hand, it should stay. New bindings should use PyBank and PyBank was developed in a way that makes sure that calls compatibility is preserved between the old and new bindings.
There was a question about using GOI to make bindings to objects creating in another language: Gtk# objects, for example. Colin said this is really, really hard. There's the issue of two GC engines per process and memory management issues that seem unsolvable in a sane way.
Shaun asked about rebasing gtkdoc on top of GOI to better extract the metadata from these annotations. Colin is looking forward to this but some work remains to get to that point.
A tangent took off about moving the scanning in to a proper GCC compiler plugin related to GCC annotations. Colin was a little worried about what would happen when people try to use other languages.
Someone wondered about best-practices for writing an application to be prepared for polyglot programming: for example a game that wants to add a Lua engine for scripting. Colin said that you're 85% of the way there just by using GObject. Other than that, you don't need to do anything else: there's no need to break out in to a shared library.
This session was run by Pierre-Luc Beaudoin. Pierre-Luc said that this has feature been wanted for a long time and is just now coming to fruition. Emerillon is now available and in GNOME git. However, hostip just changed their API and, currently, the patch to fix geoclue's support for hostip's API hasn't been reviewed yet. (So geoclue is broken at the moment.)
Someone raised the issue of how security is managed in browsers and websites that request your Geolocation. Pierre-Luc said that a dialog will prompt you to send your location to the requester.
There was a question about what uses Pierre-Luc envisions. He said that the Contacts on a Map and geolocating Photos were immediate uses. Someone threw out that, later when social networking apps. are on the desktop, updating your geotag on, for example, Twitter, would be possible in an interactive fashion. (Mojito on Moblin was pointed to.)
Someone wondered what the format that comes from OpenStreetMaps is. Pierre-Luc said that it's currently tiles but there was a GSoC project to download the meta-data in raw XML format and render it via Cairo, locally.
There was a question about integrating with Google Latitude. Robert McQueen said that the Google API is rather backwards: you must constantly poke Latitude to get updates on your contacts.
A concern was raised about bandwidth needed and request sizes. Pierre-Luc said that OSM's servers are rather overloaded at the moment. Ted Gould from Canonical suggested pre-seeding the cache with all North American data, for example, for a netbook. There was a tangent about how much data you could download from OSM at once.
There was a question about letting Emerillon submit edits to OSM. Right now, a menu lets you open OSM in a browser and then edit the data.
Pierre-Luc demonstrated some some comparisons of OpenStreetMap to other online maps. There are lots of clear cases where the data in OSM is better. He demonstrated the integration of geographical data as well as public transit (mostly in Europe, right now).
He requests that everyone give Emerillon (http://www.novopia.com/emerillon) a try.
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/Outrea
Marina then gave a summary of the FSF Women's Caucus. A summary is here: http://groups.fsf.org/wiki/Womensca
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.
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/CheatS
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.
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.
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.
(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.
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.
I'm leaving in a few hours for the airport; about 12 hours from now I'll be in Boston. I'm really looking forward to this trip even though the weather forecast calls for rain. It'll be inside where the cool stuff will be happening: MIT Sloan.
I have three major objectives for this trip: merge the Clutter Gnibbles port to master, make at least two of the Clutter+Seed games created by Tim Horton enabled by default, and to educate myself.
On that last point, education, I'm looking forward to Shaun's session on documentation which I still think of as black magic. Also, I will be paying attention to what everyone thinks GNOME 3.0 means to them so that I can articulate whatever that is to others. I also hope to absorb some of the genius of the awesome people whom will be there.
Spare time allowing, I'd like to do some hacking on GNOME Shell and get a better understanding of inner-workings of Clutter so that I can better understand some bugs that I'm working on fixing.
On a purely selfish note, I will be keeping an eye open for someone with an N900. I'm waffling on whether it's worth the investment for development since it's Clutter 0.8 and not 1.0.
Looking forward to getting some awesome work done!
An emerging theme is that m4a on Linux is pain.
May I gently suggest--judging by your narrative and the laughably over-engineered, un-usable comment system you have deployed on your blog--that the problem is with the user, not Linux. How can you make such a general statement about the state of Linux audio when you didn't consider a single modern music player other than the one that was just re-written?
Perhaps you had a requirement that you try all of the most obscure audio players you could come up with. But, if so, you should likely mention that in your narrative--you didn't. And if if that was the reason for the list that you tried, that hardly reflects the state of the work of people whom, you know, actually care about having modern desktops than can, say, compare to a Mac. Here are a few such projects which are quite modern, comparable to a music player you might find on a Mac, and handle m4a just fine, thank you: Banshee, Rhythmbox and VLC.
Don't go off in to the wilderness and then complain about the lack of good public sanitation.
Nothing has really changed versus the Clutter 0.8 version but the port has provided the opportunity to resolve some performance issues and copy Neil Roberts' clever texture cache from Aisleriot's experimental Clutter backend to Gnometris. Also, as a result of the libgames-support addition of libcanberra-gtk for sound, the sdl-mixer is no longer required for audio mixing of the sound effects (as long as you have PulseAudio). I tried to record sound for this screen cast, but PulseAudio would not allow recording from the sink monitor without some nasty buffer under-runs and 100% CPU utilization.
On the topic of CPU utilization, it's less than 5% while playing--so it turned out battery friendly. Also, note that I'm running this in a compositor. So, DRI2 seems to be quite happy with this.
This resembles very closely what you'll see in GNOME 2.28. Clutter is mandatory for Gnometris for 2.28. In a later post, I will discuss which games are slated for Clutter in 2.30.
There are a number of small, cosmetic issues that need to be resolved. If I have time, I may add a few additional effects.
Enjoy!
(Also this probably applies to retail HTC Magic / T-Mobile G1 devices.) I am posting this so that someone else can find this without the massive amount of searching I had to do to get this to work. First of all, you should not use the udev rule that is floating around. udev is the wrong way to go about this; I've been using this method for nearly six months and its flaky and insecure. I decided to finally figure out how to do this correctly and that it what follows.
Create the following file as /etc/hal/fdi/policy/android.fdi:
<match key="usb_device.vendor_id" int="0x0bb4">
<match key="usb_device.product_id" int_outof="0x0c01;0x0c02">
<merge key="pda.platform" type="string">android</merge>
<append key="info.capabilities" type="strlist">access_control</append>
<merge key="access_control.file" type="copy_property">linux.device_file</merge>
<merge key="access_control.type" type="string">pda</merge>
</match>
</match>
hal's inotify support should magically discover it and the next time you plug in your phone, it will become ACL controlled. The output of ls -lR /dev/bus/usb/003 shows a "+" that indicates that an ACL is on the device node:
/dev/bus/usb/003/: total 0 crw-rw-r-- 1 root root 189, 256 2009-06-05 16:35 001 crw-rw-r--+ 1 root root 189, 257 2009-06-05 16:37 002
And now your adb command should just work and only for the currently logged in users. You can tweak the people who get access to pda devices using polkit-gnome-authorization and browsing to org.freedesktop.hal.device-access Directly access PDA devices
.
You should note that as of the very moment of this writing this is all getting moved in to DeviceKit, though I suspect this hal method will continue to work for a few more years on most distributions.
Update 2009-07-06: All of this is broken on the latest versions of various parts as hal is in the process of being aggressively purged from the newest distros. The new, officially blessed method is to use udev-acl support which grants access to anyone who is in the ConsoleKit database at the time that the phone is attached to the computer. udev-acl was just moved to udev proper from a seperate module that was called udev-extras (now deprecated). So, you need at least udev-144 and the latest ConsoleKit to get this new method to work. I will update again once I have the new rules.
Profile
![[info]](http://l-stat.livejournal.com/img/userinfo.gif)
jasondclinton- Jason D. Clinton
Syndicate
