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 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 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.
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.
I have managed to stay away from video games for the past few months but decided to pick up one of my old favorites and spend a little time playing. Much to my dismay, 3D performance had regressed since the last time I played a full-on video game. Most FOSS and commercial games were running at 10 FPS or so. 32 and 64 bit. 100% CPU utilization.
Well, after running some oprofile and sysprof stuff, I discovered that some 60% of the CPU was being spent on in-Xorg and in-Kernel video computation. So, I thought surely it was related to some new DRI2 stuff I was running. So... I went backwards two years in Intel graphics driver development. No change; little faster. I went forward to the very latest and greatest stuff (and X, kernel and userspace Mesa): Gallium3D with DRI2 state tracker on KMS. 30% speed up but still ~15 FPS on average. So it wasn't the driver...
Finally, I decided to pull out the big guns and SSH in to my laptop while playing to watch various things. During this, I discovered that CPUFreq ondemand never raised my frequency above 800MHz. "What?" I thought, "Surely ondemand is still reliable... isn't it?" We've been recommending to people that they always use ondemand since at least the 2.6.9 days. So, after:
sudo cpufreq-set -c 0 -g performance sudo cpufreq-set -c 1 -g performance
And running every game I have, beautifully, at generally around 60 FPS (vsync), I was armed with new information to Google. And indeed, there are reports starting around mid-last year that ondemand was having major regressions. And they appear to have been largely ignored, so far.
So, does anyone know what the hell is going on with ondemand?
Here's some anecdotal evidence which may help: computational benchmarks which do 100% of their calculation in user-space correctly scale the CPU; anything which performs a portion of its work inside the kernel (graphics related stuff) does not scale the CPU
For now, my laptop has roughly 50% battery life. *sigh*
Update 2009-04-12: I had been building my own kernel throughout the mentioned series and then switched to the official Debian 2.6.29 series--the problem was still there. A week ago, I switched to Fedora--to get closer to Gnome development in more aspects--and discovered that Fedora's build of 2.6.29 is not affected. I haven't had a chance to look it what the underlying differences might be but perhaps some enterprising person will beat me to it.
The purpose of the blog post is to give deserved kudos to everyone involved in the Linux filesystem stack--especially Theodore Tso--for their excellent work.
My test system is a Intel ICH10-based laptop (Lenovo ThinkPad T400) with a 100GB 7200RPM 2.5" drive.
Conversion to
I made the switch to ext4 about the same time I installed 2.6.29-rc5: some two weeks ago. The method that I chose to use to do the conversion was simple: copy everything off to a USB disk, format the rootfs and copy it back. It is possible to do an in-place conversion from ext3 to ext4 but all the existing files on the partition will not be in the new extents format. This feature decreases the metadata overhead, reduces fragmentation and massively assists in speeding up fsck. I did this in a rescue environment[0] with kernel 2.6.28, and:
# cryptsetup luksOpen /dev/sda5 sda5_crypt # vgchange -ya # mkdir /mnt/rootfs # mount /dev/mapper/encrypted0-root0 /mnt/rootfs # mkdir /mnt/backup # mount /dev/sdb1 /mnt/backup (external ext3 formated USB HDD) # rsync -av /mnt/rootfs/ /mnt/backup/ (SELinux people probably want -X here) # umount /mnt/backup # umount /mnt/rootfs # mkfs.ext4 /dev/mapper/encrypted0-root0[1] # mount /dev/mapper/encrypted0-root0 /mnt/rootfs # rsync -av /mnt/rootfs/ /mnt/backup/ (SELinux people probably want -X here) # vim /mnt/rootfs/etc/fstab (change ext3 to ext4) # mount -t proc none /mnt/rootfs/proc # mount -o bind /dev /mnt/rootfs/dev # mount -t sysfs none /mnt/rootfs/sys # mount /dev/sda3 /mnt/rootfs/boot (mounting the regular /boot partition) # chroot /mnt/rootfs # update-initramfs -k all -u # exit # umount /mnt/rootfs/boot # umount /mnt/rootfs/sys # umount /mnt/rootfs/dev # umount /mnt/rootfs/proc # umount /mnt/rootfs # fsck.ext4 /dev/mapper/encrypted0-root0 (just for good measure, wasn't that fast!)
At this point, I was able to reboot and have a normal boot process (except faster). Note that converting your /boot partition doesn't appear to be a great idea, at the moment; grub2 should fix that soon-ish.
Subjective speed
I immediately noticed that my boot process was about twice as fast as before. However, there could be some unintended bias here[2]. Most notably, the GNOME panel appears much sooner after GDM login.
I've been through two full fsck operations after my two weeks of use, both took less than 30 seconds--down from 5 minutes before.
Most notably, fsync(FD) now flushes the file to disk, not all operations in the commit buffer. This single change makes Firefox 3 finally not suck. XFS users have had this feature for awhile, as well. I am quite happy to have my shinny new laptop behaving snappy no matter how many applications I have open. I can can have Tracker merging indexes, be running an aptitude update, and browsing in Firefox 3 without any one of these bringing the system to its knees.
Stability
Unrelated to this, I'm fighting a series of Intel Graphics stability issues while doing development on DRI2--mostly for compitor+Gnometris work. I am crashing my laptop at least once a day; usually in the form of a hard-lock.
After two weeks of this, I haven't yet lost any data or witnessed any zero-length files.
I do have a healthy backup regimen, though, to an encrypted, USB HDD.
Resizing
I have--until now--managed to avoid the gritty details of how LVM and LUKS actually work. So, after many false starts, copious amounts of documentation reading and many careful attempts, I managed to succeed is a major reorganization of my laptop disk layout--without losing any data. It is possible to resize in this environment. At some point, I should write up how I did it. It's not for the faint of heart.[0] I made my own USB-based rescue environment using Live Helper from the Debian Live project--which also rocks, incidentally. USB-based live environments boot much fast than their CD-base equivalents and don't waste a CD in the process.
[1] Debian default features are has_journal,extents,huge_file,flex_bg,un
[2] The process of moving everything off and then back on is not really representative of the way file system allocations occur during a normal installation process. So, I could be loading the extents-based allocator in such a way to causes files in boot-central directories such as /bin, /sbin, /etc, and so on, to be allocated in very close proximity to each other which may not neccissarily be the case after a fresh installation. YMVV.
Clue: if you're about to give a program you've never used before random commands because you think it should behave how you in your divine, infinite wisdom believe it should; and because the company you work for has a horse in this race and they can do no wrong; and because you can't be bothered to look up what you want to do first--you know, actually just read the links you're going to drop in your mindless, ignorant rant in your blog--just STOP. The right thing to do would be to actually read the documentation you were about to link to before you make yourself look like ********** in public.
From the very same Git Tutorial that you were about to link to in a giant section titled Using git for collaboration
you could, you know, look at the command you think you might want:
Git can also be used in a CVS-like mode, with a central repository that various users push changes to; see git-push(1) and gitcvs-migration(7).
And since you're a very smart person with a history of working with VCS's and a resume a mile long in the FOSS community, you know that that's a giant red flag that you're about to force the tool you're using in a mode that is not distributed.
But, whatever, why do all that when you can feign ignorance and continue to contribute to a months long tirade by Bazaar supporters and Canonical employees and contractors about how terrible, terrible git is and won't someone just think of the poor children? Never-mind that the entire section titled Using git for collaboration
makes it clear that cloning your repo is exactly what you want to do.
Can everyone trying to derail this move just find something better to do with their time. This is getting really, really old. I don't care what DVCS we get but now that we're finally, about to have one, it would be nice if the whining stopped. Or if there is whining, it's researched a little before it's posted.
Taking suggestions from the last post, I rewrote the keyboard-driven block movement code so that callbacks were reduced by a factor of 16. This allows for smoother animation and a continuous ligature of the blocks so that they are never more than 60 ms away from their final resting place. This makes the UI much more responsive to user input and should make hardcore players very pleased.
High quality H.264
Low quality OGV (grumble)
Flash video on Vimeo
I got rid of the spinning preview (yes, it's still off-center) and replaced it with a one-time pulse effect. I agree it's less annoying. Looking for opinions on the new effect.
I was able to reduce the number of callbacks throughout the code by a huge amount. This makes the animation much snappier as frames are not dropped while duplicate callbacks are dispatched.
The underlying code has lots of room for improvement. I need to think a little more about the location of the data structures in the code. I think it can be simplified significantly. There are a few leaks here and there but nothing major.
One caveat in all this: I uncovered two major bugs in Clutter. The first one has already been fixed by Emmanuele Bassi in Clutter 0.8.7 (Thank you! Sorry I keep pestering you!)--which hasn't been released yet. The second I reported just a few hours ago so we'll have to see what happens with that. The upshot is that you cannot run Gnometris with --enable-clutter from trunk right now unless you use git clutter-0-8 HEAD and you revert commit ce584541f113d4b5a4b5823b31f45e52f2da0da2.
I will update this post tomorrow morning with the Flash version once the Vimeo upload has gotten through their two hour long wait queue.
Profile
![[info]](http://l-stat.livejournal.com/img/userinfo.gif)
jasondclinton- Jason D. Clinton
Syndicate
