Easy Compiz Tricks February 3rd, 2010

A while ago I tweaked Sam’s simple animations plug-in for Compiz, mainly so windows I minimized would slide away to match some of my other settings. This was to strike a balance between usability and performance, since none of these effects use alpha blending. During this time I made some jokes about a Spinner Rims plug-in to illustrate how people rev the Compiz engine when they first hop behind the wheel. Oddly enough, I’ve actually had others ask me for this plug-in and had Google Alerts on random forums about it – as if it was real, which perplexes me.

Sometimes applications don’t always (or can’t) describe a window correctly, which can make Compiz use a different animation. For example, when I drag a tab out of Google Chrome it uses my open animation for the window, which really disrupts the feel of drag and drop tabs that otherwise is very elegant. Another example is with generic frameworks like Adobe AIR or Java Swing, where all the widgets are treated the same. How do we work around this?

Luckily, Compiz is well equipped to handle this. You’ll need the Compiz Configuration Settings Manager (CCSM), which I think almost everyone has installed, and it should exist out-of-the-box so users can see how powerful the software really is. In the case of Google Chrome:

  1. Open CCSM (ALT+F2 ccsm or Preferences/Compiz Configuration Settings Manager)
  2. Click the Animations plugin
  3. Press the New button underneath the list
  4. Select None for the animation with the lowest possible duration
  5. Click the Add icon near the Window Match field
  6. Click the Grab button and target Chrome (it should give you class=Chromium-browser)

Make sure this is moved up the list so it overrides any other settings, since it’s specific to Chrome. You can later go back and click the Grab button again and add more windows to the blacklist. Now when you drag tabs in Chrome they won’t be so awkward. After getting used to no opening animation with one application, I ended up disabling them for all. I still use the other animations, but I’ve enjoyed not having any opening animations for non-decoration windows.

Compiz, Patents, and Ubuntu January 22nd, 2010

No, this isn’t about the stupid max_waves conflict with Apple’s patent that everyone has been ranting (and working around) for the last few years. From what I hear the future 0.9.0 release won’t be hampered by it, but how does Compiz fair with patents? Who made Compiz, and who’s working on it today?

From my understand the original Compiz, before all the forks and subsequent merges, was developed by Novell via David Reveman with help from others. Now, in the aftermath of whatever happened, most (if not all) of the core developers aren’t around – and Novell has moved on too. While the developers are gone they did take a little something with them.

SYSTEM AND METHOD FOR EVENT-BASED RENDERING OF VISUAL EFFECTS is patent application #20080313540 by Anna Dirks, David Reveman, Stephen Carter, and Scott Isaacson filed back in 2007. This patent would go to someone who deserves it, but can it ever be used against the project in the future? Now Apple is filing for a patent on head tracking, which is something we’ve seen Compiz devs and plug-in writers have been doing for a while now. We want developers to get attributed for their hard work in Open Source, but nobody should have control over the ideas that power these projects.

Ubuntu is using the old 0.8.x branch written in C, while the team has moved on to the 0.9.0 release written in C++. With Ubuntu 10.4 (Lucid Lynx) being an LTS, it’s obviously not going to be in that release. Even once the package is more mature, there is still a big dependency issue lingering. While it’s obvious that the refactoring of the code yielded performance and maintainability benefits, it’s using libboost and favoring C++. With GIMP kicked off the CD to make space, what’s going to happen to Compiz?

Update 1: There is a thread going on UbuntuForums.org related to this, although some of it’s just anti-Apple rhetoric. I wish people would stop hi-jacking real discussion with this crap.

Update 2: I asked Novell if they could shine any light on the situation on January 26, 2010. Hopefully they are willing to at least take a look and get back with something besides a dear-john letter.

Bugs with GDK_NATIVE_WINDOWS January 18th, 2010

There are two bugs that I encounter a lot in Ubuntu 9.10 (Karmic) that irritate me a lot. Both bugs involve mouse clicks not being registered. I’ve got some workarounds and fixes, but first some background on these bugs.

Flash Bug (#410407)

This bug has been misidentified as a bug in Compiz, when in fact it’s a bug in Adobe’s Flash Player plug-in. It causes mouse clicks to not be handled by the Flash application. The bug is inconsistent – it’s an all or nothing thing. You’ll either get the bug on a video, or you won’t, and sometimes it can be coaxed into working by spamming clicks.

Eclipse Bug (#443004)

This bug has caused a lot of wasted time. Similar to the bug with Flash, clicking on a button with some dialogs will not register. It’s also inconsistent, which can be a real pain. Some dialogs in Eclipse can span many pages, such as the Export to JAR dialog.

Both of these bugs are related to a change that happened regarding GDK, the underlying method GTK-style applications use to draw things instead of calling X directly. I think the core problem is:

A small gotcha is that the GDK_WINDOW_XID() call is no longer a trivial accessor for the XID of the window, and thus must not be called from another thread without taking locking precautions.

This matches the inconsistency of the problems, since it’s a related to concurrency.

To combat the bug in Eclipse I’ve started using the repository version, since the SWT-related bug was fixed and they added support for user plugins.

The workaround for the Flash bug isn’t as nice, since Adobe is the master of making horrible “fixes.” For example, they pulled the rug out from underneath a lot of websites using Flash player to do the heavy lifting of uploading multiple files by requiring the file selection dialog to be initiated by a user interface interaction. Essentially you have to tell Flash not to enjoy the benefits of client-side windows by modifying /usr/lib/nspluginwrapper/i386/linux/npviewer to look something like this:

#!/bin/sh
TARGET_OS=linux
TARGET_ARCH=i386
GDK_NATIVE_WINDOWS=1
. /usr/lib/nspluginwrapper/noarch/npviewer

So that’s two features Adobe has nerfed in one configuration file (64-bit and client-side windows)

Compiz Documentation Tag Style Vote October 22nd, 2009

I’m getting mixed opinions about what kind of doc tags to use in the Compiz project. Overall there are two choices that everyone seems to be okay with. In no particular order the two most popular methods are:

///
/// This does that
///

Or

/**
 *  This does that
 */

The latter is nice because it matches how javadoc works, which I think has made Java (and it’s APIs) one of the best documented languages around. The former I found nice because it’s easy to align in all text editors quickly (always type three forward slashes), but is more verbose. In source the former also seems to make it easier for me to quickly scan for doc tags, since most multi-line comments in C++ are done with /* notation.

Erkin pointed out that we can easily nest /// style of comments inside of /* comment blocks, which makes it easier to comment out portions of code that are documented, such as this:

/*

... code ..

///
/// Method we don't want
///
int foo();

... code ...
*/ 

Feel free to make your arguments known here. If you see me on IRC feel free to bring it up, but please use the poll below or make a comment so we can get a real idea of what to commit to before we start merging all the doc’d code. This is a good way to avoid many git quilting sessions later.

[poll id="2"]

Compiz 0.9 C++ compared to 0.8.4 C October 21st, 2009

Comparison of the C version (0.8.4) of Compiz and the new C++ (0.9) branchComparison of the Compiz Core in C++ and CHere is an early look at some of the changes I’ve been investigating as documentation continues on the new Compiz 0.9 branch. The community and development team are pretty awesome folks, and I would like to take a moment to thank everyone in the IRC, Forums, and Planet.

This graph is simply information I collected about the size of the source code files for various plugins. There is also a general graph comparing the sizes of the core. I had started to do a comparison of binary sizes, but because of the optimizations and debugging builds I have – it might be a while before I could get accurate numbers for that.

Compiz Fusion Plugin Development October 18th, 2009

compiz-spinner-rimsIn between the massive changes to the site (see my twitter) and setting up new developer relationships, I was inspired to work with Compiz Fusion – or what most now just call Compiz. I’ve always wanted to do some plugins, but the problem is jumping into their largely undocumented API. That’s changing a bit now, since there seems to be a better effort and they’ve got a nice start with the Compiz Wiki. Doesn’t it always seem you can just throw MediaWiki (or in this case MoinMoin) at something and it appears to fix itself.

In the past we’ve all pimped out Compiz to the point where we’re basically expecting a Spinner Rims plug-in, but I want to change that a bit. Firstly I think that many effects use too much blending with Opacity, which can be sluggish on older or low-performance hardware. Plus I think the Dodge focus effect, Show Desktop, and other effects that simply “move” windows look really clean.

Read the rest of this entry »