With the release of the WebKit-based Chrome browser, Google also introduced a handful of new backends for the browser engine including a new HTTP stack and the Skia graphics library. Google’s Android WebKit code drops have previously featured Skia for rendering, though this is the first time the sources have been made freely available. The code is apparently derived from Google’s 2005 acquisition of North Carolina-based software firm Skia and is now provided under the Open Source Apache License 2.0.

Weighing in at some 80,000 lines of code (to Cairo’s 90,000 as a ballpark reference) and written in C++, some of the differentiating features include:

• Optimised software-based rasteriser (module sgl/)
• Optional GL-based acceleration of certain graphics operations including shader support and textures (module gl/)
• Animation capabilities (module animator/)
• Some built-in SVG support (module (svg/)
• Built-in image decoders: PNG, JPEG, GIF, BMP, WBMP, ICO (modules images/)
• Text capabilities (no built-in support for complex scripts)
• Some awareness of higher-level UI toolkit constructs (platform windows, platform events): Mac, Unix (sic. X11, incomplete), Windows, wxwidgets
• Performace features
  • Copy-on-write for images and certain other data types
  • Extensive use of the stack, both internally and for API consumers to avoid needless allocations and memory fragmentation
  • Thread-safety to enable parallelisation

The library is portable and has (optional) platform-specific backends:

• Fonts: Android / Ascender, FreeType, Windows (GDI)
• Threading: pthread, Windows
• XML: expat, tinyxml
• Android shared memory (ashmem) for inter-process image data references

Hello world

In this simple example we draw a few rectangles to a memory-based image buffer. This also demonstrates how one might integrate with the platform graphics system to get something on screen, though in this case we’re using Cairo to save the resulting image to disk:

#include "SkBitmap.h"
#include "SkDevice.h"
#include "SkPaint.h"
#include "SkRect.h"
#include <cairo.h>
 
int main()
{
  SkBitmap bitmap;
  bitmap.setConfig(SkBitmap::kARGB_8888_Config, 100, 100);
  bitmap.allocPixels();
  SkDevice device(bitmap);
  SkCanvas canvas(&device);
  SkPaint paint;
  SkRect r;
 
  paint.setARGB(255, 255, 255, 255);
  r.set(10, 10, 20, 20);
  canvas.drawRect(r, paint);
 
  paint.setARGB(255, 255, 0, 0);
  r.offset(5, 5);
  canvas.drawRect(r, paint);
 
  paint.setARGB(255, 0, 0, 255);
  r.offset(5, 5);
  canvas.drawRect(r, paint);
 
  {
    SkAutoLockPixels image_lock(bitmap);
    cairo_surface_t* surface = cairo_image_surface_create_for_data(
        (unsigned char*)bitmap.getPixels(), CAIRO_FORMAT_ARGB32,
        bitmap.width(), bitmap.height(), bitmap.rowBytes());
    cairo_surface_write_to_png(surface, "snapshot.png");
    cairo_surface_destroy(surface);
  }
 
  return 0;
}

You can build this example for yourself linking statically to the libskia.a object file generated during the Chrome build process on Linux.

Not just for Chrome

The Skia backend in WebKit, the first parts of which are already hitting SVN (r35852, r36074) isn’t limited to use in the Chrome/Windows configuration and some work has already been done to get it up and running on Linux/GTK+ as part of the ongoing porting effort.

Bamboo scaffolding is a low resolution grid used to produce a higher resolution structure. Living in Guangzhou is inspirational because of the scale of buildings, real imaginations constructed, and accessibility to cheap materials and constant laborers.

The above is a view from outside Lu’s parents house in the midst of a city under construction.

The first version of the Bamboo structure being constructed. It has received a second revision now to make it much much stronger, all from 24 pieces of 7 meter bamboo.

For Cantocore, opening on friday here in Guangzhou from 8-10 PM, I’ve built, with the assistance of Chinese carpenters, a large 7 meter structure of bamboo which might be likened to Big Ben, hence, its a Chinese Big Ben.

I’ll have more notes about my project tomorrow at the unveiling Plus, have some code to write still (at the top of a 7 meter bamboo structure).

Gallium3D interfaces don't match any particular graphics API 1 to 1. Likewise, conformance tests end up not doing a good coverage of Gallium3D's interface either: sometimes a single Gallium3D feature is tested in many different tests; sometimes a feature ends up not being exercised by any test, so bugs are only detected in applications, where they are much harder to narrow down. And so appeared the need to write some tests at the Gallium3D interface level.

Since the ability to write tests quickly was important, and the running speed not so important, I've decided to write a Python bindings, so that tests could be scripted in Python. These bindings wrap around the pipe driver, so that they look like a pipe driver from the Python script point of view, and look like a state tracker from the pipe driver point of view.

About the tests there is not much to write about yet. I wrote tests for texture formats that allowed to squash the bugs I was searching for, and I imagine that more tests will be added as needs justify it.

However, having a Gallium3D bindings in Python opens several doors. One particularly is that it becomes a nice sandbox to learn Gallium3D. For example. here is the code to draw a single triangle:

def test(dev):
    ctx = dev.context_create()

    width = 255
    height = 255

    # disabled blending/masking
    blend = Blend()
    blend.rgb_src_factor = PIPE_BLENDFACTOR_ONE
    blend.alpha_src_factor = PIPE_BLENDFACTOR_ONE
    blend.rgb_dst_factor = PIPE_BLENDFACTOR_ZERO
    blend.alpha_dst_factor = PIPE_BLENDFACTOR_ZERO
    blend.colormask = PIPE_MASK_RGBA
    ctx.set_blend(blend)

    # no-op depth/stencil/alpha
    depth_stencil_alpha = DepthStencilAlpha()
    ctx.set_depth_stencil_alpha(depth_stencil_alpha)

    # rasterizer
    rasterizer = Rasterizer()
    rasterizer.front_winding = PIPE_WINDING_CW
    rasterizer.cull_mode = PIPE_WINDING_NONE
    rasterizer.bypass_clipping = 1
    rasterizer.scissor = 1
    #rasterizer.bypass_vs = 1
    ctx.set_rasterizer(rasterizer)

    # viewport (identity, we setup vertices in wincoords)
    viewport = Viewport()
    scale = FloatArray(4)
    scale[0] = 1.0
    scale[1] = 1.0
    scale[2] = 1.0
    scale[3] = 1.0
    viewport.scale = scale
    translate = FloatArray(4)
    translate[0] = 0.0
    translate[1] = 0.0
    translate[2] = 0.0
    translate[3] = 0.0
    viewport.translate = translate
    ctx.set_viewport(viewport)

    # samplers
    sampler = Sampler()
    sampler.wrap_s = PIPE_TEX_WRAP_CLAMP_TO_EDGE
    sampler.wrap_t = PIPE_TEX_WRAP_CLAMP_TO_EDGE
    sampler.wrap_r = PIPE_TEX_WRAP_CLAMP_TO_EDGE
    sampler.min_mip_filter = PIPE_TEX_MIPFILTER_NONE
    sampler.min_img_filter = PIPE_TEX_MIPFILTER_NEAREST
    sampler.mag_img_filter = PIPE_TEX_MIPFILTER_NEAREST
    sampler.normalized_coords = 1
    ctx.set_sampler(0, sampler)

    # scissor
    scissor = Scissor()
    scissor.minx = 0
    scissor.miny = 0
    scissor.maxx = width
    scissor.maxy = height
    ctx.set_scissor(scissor)

    clip = Clip()
    clip.nr = 0
    ctx.set_clip(clip)

    # framebuffer
    cbuf = dev.texture_create(
        PIPE_FORMAT_X8R8G8B8_UNORM, 
        width, height,
        tex_usage=PIPE_TEXTURE_USAGE_DISPLAY_TARGET,
    )
    _cbuf = cbuf.get_surface(usage = PIPE_BUFFER_USAGE_GPU_READ|PIPE_BUFFER_USAGE_GPU_WRITE)
    fb = Framebuffer()
    fb.width = width
    fb.height = height
    fb.num_cbufs = 1
    fb.set_cbuf(0, _cbuf)
    ctx.set_framebuffer(fb)
    _cbuf.clear_value = 0x00000000
    ctx.surface_clear(_cbuf, _cbuf.clear_value)
    del _cbuf
    
    # vertex shader
    vs = Shader('
        VERT1.1
        DCL IN[0], POSITION, CONSTANT
        DCL IN[1], COLOR, CONSTANT
        DCL OUT[0], POSITION, CONSTANT
        DCL OUT[1], COLOR, CONSTANT
        0:MOV OUT[0], IN[0]
        1:MOV OUT[1], IN[1]
        2:END
    ')
    ctx.set_vertex_shader(vs)

    # fragment shader
    fs = Shader('
        FRAG1.1
        DCL IN[0], COLOR, LINEAR
        DCL OUT[0], COLOR, CONSTANT
        0:MOV OUT[0], IN[0]
        1:END
    ')
    ctx.set_fragment_shader(fs)

    nverts = 3
    nattrs = 2
    verts = FloatArray(nverts * nattrs * 4)

    verts[ 0] = 128.0 # x1
    verts[ 1] =  32.0 # y1
    verts[ 2] =   0.0 # z1
    verts[ 3] =   1.0 # w1
    verts[ 4] =   1.0 # r1
    verts[ 5] =   0.0 # g1
    verts[ 6] =   0.0 # b1
    verts[ 7] =   1.0 # a1
    verts[ 8] =  32.0 # x2
    verts[ 9] = 224.0 # y2
    verts[10] =   0.0 # z2
    verts[11] =   1.0 # w2
    verts[12] =   0.0 # r2
    verts[13] =   1.0 # g2
    verts[14] =   0.0 # b2
    verts[15] =   1.0 # a2
    verts[16] = 224.0 # x3
    verts[17] = 224.0 # y3
    verts[18] =   0.0 # z3
    verts[19] =   1.0 # w3
    verts[20] =   0.0 # r3
    verts[21] =   0.0 # g3
    verts[22] =   1.0 # b3
    verts[23] =   1.0 # a3

    ctx.draw_vertices(PIPE_PRIM_TRIANGLES,
                      nverts, 
                      nattrs, 
                      verts)

    ctx.flush()

And this is the result:

In summary, you create several state atoms, bind them to the context, and then send the geometry through the pipe driver. Full source available in Mesa3D's git repository.

To use Gallium3D's Python bindings follow these instructions.

BTW, XDS 2008 is happening now. Too bad I couldn't go this year, as I would like to meet everybody. I hope you're having a great time!

Developers seem to do a lot of fighting with bleeding-edge libraries installed in a --prefix, so I thought I'd share how I develop telepathy-glib (a library) and telepathy-gabble (a program using that library).

~/Collabora/telepathy/tpglib on my laptop is a git clone of telepathy-glib.git, branched using the process I documented on http://telepathy.freedesktop.org/wiki/Git, which is basically:

• clone the upstream repository (git+ssh://git.collabora.co.uk/git/telepathy-glib.git in this case) into your home directory on the server (git+ssh://people.collabora.co.uk/home/smcv/public_html/git/telepathy-glib-smcv.git in this case)
• clone that onto your laptop
• on your laptop, add "upstream" as a remote, tracking the upstream repository
• this reduces mistakes, because "git push" pushes to origin (which is in my home directory) for review, and "git push upstream" is necessary when I actually want to commit to the upstream repository

~/Collabora/telepathy/gabble is a git clone of telepathy-gabble.git, using the same process.

In my Gabble checkout, I used to configure like this:

cd ~/Collabora/telepathy/gabble
TP_GLIB_CFLAGS="-I${HOME}/Collabora/telepathy/tpglib" \
TP_GLIB_LIBS="${HOME}/Collabora/telepathy/tpglib/telepathy-glib/libtelepathy-glib.la" \
sh ./autogen.sh

This would make libtool link Gabble against the copy of telepathy-glib built by my bleeding-edge git checkout, without ever needing to install it. This allowed me to try out my latest telepathy-glib changes with Gabble's more extensive regression tests, which was a great win.

It also meant I could develop Gabble branches that required a not-yet-released telepathy-glib, and all without touching my system copy of telepathy-glib (the one I use to run Empathy and talk to people - which is the packaged version from Debian unstable or experimental).

The reason I could do this is that I laid out the telepathy-glib source tree in The Right Way™, which is: if a header is designed to be used via #include <my-library/foo.h>, then it goes in a my-library/ directory in the source tree, and includes other headers (even from the same project) with #include <my-library/other.h>.

This means you can just add the top directory of the source tree to your include path (which automake does by default) and the right thing will happen.

(Actually, this is a slight simplification of the truth: because telepathy-glib contains generated headers, you have to add the top directory of the build tree to your include path too, if you want to support out-of-tree builds. Which, of course, you do.)

Other projects that do this correctly include GLib and Avahi. Avahi is a particularly interesting example because it has numerous libraries in the same tarball (including avahi-common, avahi-core, avahi-glib and avahi-gobject, which form a dependency chain).

Projects that don't do this correctly include telepathy-mission-control (which is on my hit list for further swamp-draining) and libtelepathy (which is obsolete).

Today I committed a patch to telepathy-glib, inspired by GStreamer, to generate telepathy-glib-uninstalled.pc. The presence of this patch simplifies the process further, to:

PKG_CONFIG_PATH=$HOME/Collabora/tpglib/telepathy-glib sh ./autogen.sh

This has the same benefits as setting TP_GLIB_CFLAGS and TP_GLIB_LIBS, but is easier to remember, and is more future-proof against changes to telepathy-glib.

It only works because pkg-config has a special case for this situation - if you ask for the package "foo", pkg-config will always look for foo-uninstalled.pc before foo.pc.

From the "doing sysadmin over wobbly 3G while waiting for our plane to be allowed to take off" department comes this bit of mailing list setup. By his own admission, Rob is better at configuring Postfix than he is at making blog posts, so I get to be the one posting this...

09:58 <@Robot101> my postfix -> eoc integration is basically ninja, if I might 
                  say so myself
09:58 <@Robot101> so, an eoc transport in master.cf:
09:58 <@Robot101> eoc       unix  -       n       n       -       10      pipe 
                  user=list argv=/usr/bin/enemies-of-carlotta --quiet 
                  --incoming --sender=${sender} --recipient=${recipient}
09:59 <@Robot101> then in main.cf:
09:59 <@Robot101> eoc_destination_recipient_limit = 1
09:59 <@Robot101> virtual_mailbox_domains = lists.collabora.co.uk
09:59 <@Robot101> virtual_mailbox_maps = pcre:/etc/postfix/list_transports
09:59 <@Robot101> transport_maps = pcre:/etc/postfix/list_transports
09:59 <@Robot101> then a script/cron:
09:59 <@Robot101> su -c "enemies-of-carlotta --show-lists" list | sed 
                  's,\(.*\)@\(.*\),/^\1(-[^@]*)?@\2$/ eoc,' 
                  >/etc/postfix/list_transports
09:59 <@Robot101> giving list_transports like this:
09:59 <@Robot101> /^test(-[^@]*)?@lists.collabora.co.uk$/ eoc
09:59 <@Robot101> (thanks to smcv for assistance with regexp-generation regexp)
...
10:01 <@wjt> ten points for using the best -named mlm
10:01 <@Robot101> 2000 points for not having a mailing list system held 
                  together with procmail, shell, duct tape, gash and string

Just noticed today that the FSF managed to get Stephen Fry to make a video in celebration of the 25th Anniversary of the FSF. Been a fan of Stephen for a long time, ever since I first saw him in Blackadder many years ago, so it is cool to see him doing this sort of promo for free software. Been aware that Stephen Fry has advocated free software in his blog for some time, but it is still nice to see such direct interaction with the community. The video is available in Ogg format using Theora video and Vorbis audio, which also makes me happy. I even ended up emailing them saying I be happy to convert their source material into a HD Dirac+Vorbis version if they are interested. Every time I see stuff being published in free formats it makes me feel very good about the work we are doing here at Collabora and the goals we have set for ourselves.

Dirac Everywhere

On the topic of Dirac there are a lot of fun stuff happening. One thing I failed to mention before, is that there is a Dirac Quicktime component available now. Still alpha quality, but part of the effort done to reach out to a wide a community as possible with Dirac. There has also been work happening on wider Dirac support in GStreamer and integrating that support better into GStreamer. For instance Thiago merged a patch from David Schleef to add Dirac support to the new quicktime muxer Thiago created as part of the summer of code. It already works well, but we need to do a little Pitivi hacking to enable it there. Edward hopes to get at that before the weekend. Finally Sebastian Dröge merged the transport stream muxer library and plugin into gst-plugins-bad, which also can mux Dirac video (the library used to be hosted on the old Dirac website). Sebastian will also be working on making sure that muxer can create some Playstation 3 friendly files going forward.

Also thanks to Fluendo and Zaheer we know have a working transport stream demuxer in gst-plugins-bad which of course also handles Dirac.

Centralising GStreamer plugins

On the back of this I think we will try to do a bigger effort to merge some of the external plugin repositories into GStreamer proper. For instance at Collabora we got the gst-plugins-farsight module which should have its plugins moved over. Our latest team member Mark Nauwelaerts got his GEntrans plugins which should also move over. Having a central set of repositories and plugins makes them easier to find for everyone and will also increase the ease of maintenance. And of course reduce the risk of people doing something which someone else has already done.

This new release adds support for recent OpenSuSE versions, and fixes a bug where mach fails to work because yum –version now outputs much more than the usual one line:

[thomas@ana mach2]$ yum –version
3.2.17
Installed: rpm-4.4.2.3-2.fc9.i386 at 2008-05-24 02:06
Built : Fedora Project at 2008-04-18 16:52
Committed: Bill Nottingham at 2008-04-18 22:00

Installed: yum-metadata-parser-1.1.2-8.fc9.i386 at 2008-05-24 02:07
Built : Fedora Project at 2008-02-14 13:27
Committed: Seth Vidal at 2008-02-14 22:00

Installed: yum-3.2.17-2.fc9.noarch at 2008-08-01 11:00
Built : Fedora Project at 2008-07-10 16:53
Committed: Seth Vidal at 2008-07-10 22:00

I’m sure there’s a good reason for doing that, so I guess the egg is on my face for my simplistic version parsing from before.

Soon in a Fedora repository near you, or you can get the source.

to OpenedHand on cashing out! May you all be made rich and live prosperously.

Just make sure you don’t get sucked into the Black Hole of Being Acquired, but keep hacking. Make us proud!

Things have been busy in the last few weeks (in roughly chronological order):

• fed lots of PCI fixes to Linus
• mostly finished porting the kernel modesetting bits into xf86-video-intel master
• fixed lots of gfx bugs
• hacked on GTT mapping for GEM
• argued about the upstream DRM development process
• worked to close the gap between upstream DRM and current DRM master trees
• released 2.4.97.0 of xf86-video-intel (first test release for 2.5.0)
• …and various other bits of Intel internal work

PCI

Got lots of good PCI stuff upstream this merge cycle. Mostly hotplug and PM related. Just drained the last couple of regression fixes on Monday, so things should be in pretty good shape for 2.6.27. For 2.6.28 there are bunch of random cleanups & fixes queued, and I’m trying to find time to review TJ’s PCI address space code; there’s a lot of room for improvement in what’s currently upstream, so I’m hoping his stuff will help.

xf86-video-intel

The 2.5 release is shaping up to be an aggressive one: we’ve already merged both GEM and kernel mode setting support into the tree along with a slew of bug fixes. Neither of the new features is available by default, but if you have a suitably capable kernel you can try them out and report any bugs we’ve introduced.

The bug queue on the 2D side isn’t looking too horrible, and the blocker list looks manageable. The first test release went out on Monday and I don’t think I’ve heard of any new issues specific to that release yet, so I’m fairly happy about it so far.

DRM

Since both GEM and kernel mode setting are really kernel features, I’ve been spending a lot of time in the DRM tree lately. In order for kernel mode setting and GEM to work really well, we need a way to map GEM objects using their GTT address, rather than the backing store physical address. Given that we’re doing this from a module using an ioctl, it’s a little tricky, and we also need to handle invalidation when the object is kicked out of the GTT and faulting for when it gets accessed again. This was one of TTM’s strong points, but we were hoping to get away without having to do it with GEM. Unfortunately that’s not the case, and it really needs to be done to make kernel mode setting and UXA possible, so making it work is at the top of my list at the moment.

On the process front, things are looking really good. The first step in fixing a problem is admitting that it exists. After some heated arguments on IRC and dri-devel it looks like people mostly recognize that the current DRM development scheme doesn’t isn’t very good at getting code into upstream kernel releases and ultimately out to users. Dave has proposed a new process (see this wiki page for the current thinking) that should make it much more obvious which bits are going to head upstream and which aren’t. It should also make sync’ing with other OSes easier since development will be more transparent, and hopefully occur on the mailing list a bit more than it has in the past, where developers typically just pushed stuff into the DRM master tree and hoped Dave would do the hard work to get it upstream.

There is a downside to the new process however. In the DRM (and in particular in the i915 driver), features have been accumulating for a long time, causing the diff between upstream Linux and DRM master to grow over time. So I’ve been working to narrow that gap and push mature features into the drm-next branch so that they’re ready for the 2.6.28 merge window. The i915 driver has had quite a few features not present upstream for a long time now, like pipe/plane swapping support, vblank rework support, page flipping, and a few other changes & bug fixes. Once these changes get upstream OSVs will start to pick them up and users will start seeing the benefit of the new development model. I’m not sure what’s happening with other drivers; several of them (like radeon) have similar issues, and some aren’t upstream at all (like XGI and mach64, among others), so someone will have to step up to do that work.

Overall it’s an exciting time in Linux-land; it’s really good to see so many improvements come together and get into the hands of users. Hopefully over time the lag between feature development, bug fixing and getting stuff to users will shrink even more.

I released libcanberra 0.8 a few hours ago. Biggest changes are some portability fixes for Solaris/FreeBSD, inclusion of an OSS backend (contributed by Joe Marcus Clarke) and a GStreamer backend (contributed by Marc-André Lureau). This will hopefully make certain doubts regarding libcanberra void.

Oh, and libcanberra now has a homepage.

Thanks to Dimitris Glezos PulseAudio and its auxiliary tools are now available on Fedora's Transifex for translation. If you want to contribute translations, please submit them via Transifex, which will then result in direct commits to our upstream source code repositories -- without further delay or workload on my side. Submission via other ways (bug report, mail ...) will no longer be accepted.

Submit your translations now for PulseAudio, for the volume control, and for the preferences dialog. And while we are at it, Avahi's waiting for your translations, too.

Last week we did a press barrage for the upcoming Cantocore show in Guangzhou, China! I know a lot of you are spread all throughout the globe, but nonetheless, I hope that anyone in the region can make it for the big September 5th Opening! It will be fantastic.

I wrote the exhibition text, have been coordinating fabrication, and somewhere in the midst trying to finish my project for the exhibition. We are up late right now finishing some projects and the publication is coming along nicely for the last minute print deadline for tomorrow Here is a sampling of the press text which you can read in full at cantocore.com:

Today the Cantocore Project and Ping Pong Space announced the upcoming contemporary art show, Cantocore: Import/Export in Guangzhou, China during September 2008. This initial show features contemporary artists from San Francisco and Guangzhou producing artwork around the more detailed relationship between import and export of culture and materials between Guangzhou, China and San Francisco. This first part of the Cantocore exhibition, Import, begins with an opening on Friday, September 5 from 8 PM at the brand new Ping Pong Space in Guangzhou, China. The show continues until Tuesday, September 16 with gallery hours of 2:00 PM until 10:00 PM daily. The second part of the show, Export, opens Sunday, September 21 at 8 PM until 10 PM when a special video screening developed by San Francisco’s Mission 17 titled “Stardusted” will be presented at the Ping Pong Bar from 10 PM until 11PM. The second half, Export, continues daily until Saturday, October 4 with daily hours from 2:00 PM to 10:00 PM.

The Cantocore Import/Export exhibition examines, through applied art practice, the relationship between import and export of culture between Guangzhou and San Francisco by asking a simple phrase: Are you Cantocore? Guangzhou, also called Canton, is the third most populous city in China and its province, Guangdong, is a major manufacturer of textiles and electronics for export to the United States. San Francisco has the largest import of Chinese immigrants of any US city, primarily from the Guangdong province. Chinese immigrants also created the largest Chinatown in North America in San Francisco. However, understanding the conceptual framework of Cantocore is not limited to geographic divisions, nor reductive dichotomies driven by post-colonial stereotypes such as East vs. West, nor Olympic nationalism pridefully paramount in China vs. US “non-political” sports matches. Cantocore is the reality of life versus the theory set forth by jurisdictions where people live.

The artists in the Cantocore exhibition were tasked with creating projects which explore import and export, materially and conceptually. Practically, how can one’s artwork be actualized either through fabrication locally in Guangzhou or imported from San Francisco? Guidelines for the creation of the work were left alone since modern strategies for creating artwork such as remaking, remixing, interpreting, pirating, translating, copying, and appropriating content, already espouse the Cantocore style. After the proposals were received from invited artists, curation of works took place based upon the processes, scope, location of artists and available resources to constitute this first Cantocore dialogue.

Curation for this show has been a group effort by Deer Fang, Justin Hoover, and Jon Phillips from the Cantocore Project and Wu Jay from Ping Pong Space (PPS). Layout and Design for the show is done by Pierre Picard (PPS) while wordsmithing has been handled by Nikita Choi (PPS), Jon Phillips and Deer Fang.

Exhibition Venue

#60 Xian Lie Dong Heng Lu Ping Pong Space, Guangzhou

Cantocore Import
September 6th - 26th, 2008
Opening: Friday, September 5th, 8PM – 10 PM.
Drinks after at Ping Pong Bar.

Cantocore Export
September 22nd - October 2nd, 2008
Opening: Sunday, September 21st, 8PM - 10PM

Video Screening “Stardusted” at Ping Pong Bar

September 21st 2008, 10PM – 11PM

Regular Gallery Hours
Tuesday - Sunday 2 PM – 10 PM
Gallery Closed on Monday

Ping Pong Bar Open Everyday

Also, we just updated some images of works for the show. Here is a sampling of the full post over at Cantocore.com.

For all you needing images out there, we have just up pushed out images for David Johnson who will be exhibiting a work titled “Made in China” and Guy Overfelt who is getting some magic smoke fabricated.

Guy Overfelt's Untitled (Up in Smoke) Sketch

Please check out the press section to help blog and promote this show!

So the official part of the summer of code is now over. I am sure the mentors will blog about the results in general, but since I have followed the Quicktime muxing project the closest myself and since Wim do not have a blog I thought it would be nice to give it a mention. Quicktime is a quite complicated format, orignally created with both editing in use, but also tied quiet closely to the quicktime media framwork. It also has a lot of derivatives like the MPEG4 container format and the 3GPP mobile container format. So when writing a muxer one need to take into account that the user might want a muxed file conforming to any of those 3 standards.

Anyway, Thiago Sousa Santos has been working hard over the summer and we now have the basic muxer working. With the baseline in place there are of course a lot of small details that needs to be taken care of, like adding support for all the different codecs which can go into a Qt/MP4/3GPP container format for instance. Thiego is well underway with that effort already though with h264 support added just a few days ago (I found a bug in the muxer testing it though, but I am sure we will sort that out quick enough). Other codecs we would want to support soon would be Dirac in Quicktime for instance.

The code is not yet in GStreamer CVS, but currently hosted in this SVN repository. But with the Summer of Code over I guess we can look into moving it into the main GStreamer repo. The great thing is that Thiego will continue working on the muxer even though the Summer of Code project period is over so hopefully all GStreamer users will have a top notch Quicktime/mp4/3gpp muxer to use once all major media formats are supported and tested.

So I would like to congratulate Thiego on having completed this years Google Summer of Code project in a absolutely brilliant way and thank him for the effort so far. The future looks bright!

I’ve been listening to the StackOverflow podcast for a few months. I never was into podcasting but decided I should give it a try and I decided around the time Joel Spolsky and Jeff Atwood started their podcast. I’ve followed both of their blogs for a while now, mostly because Joel is very good at explaining his opinions and has lots of experience to build on, and Jeff is refreshingly down-to-earth and prolific as a blogger. I use them as my conduit to the non-Linux side of programming, as a crutch to keep me a little bit grounded into the real world out there where 95% of people never use Linux and get their job done as well.

So, I applied for the beta, but didn’t have time this month to actually use it. I started using it last weekend, browsing, answering some questions, and so on. It’s actually a fun site, and I think it will end up being very useful. In the beginning I couldn’t do much because you need reputation to do certain actions, like voting questions up. But today I hit the 3 digit reputation score, I’ve had some questions answered, and I’ve had some answers voted up or promoted to the right answer, and it starts being useful.

It’s too soon to say, but it might end up being the single best new web site this year, and one of the few directly useful for my work. And it’s all running on Windows!

I sincerily hope us Free Software people can get past that ‘it runs on Windows’ hangup and seriously use the site when it’s available. I’ve already run into one of us going through some of the Python questions. Instead of asking the intarweb, I’m now going to ask technical questions over there. I hope you will too.

There’s a guy in Barcelona who runs an antique store. Well, maybe it’s not an antique store, because it doesn’t like like stuff my mom would actually buy. And I’m not even sure if he’s selling.

But he cooks for anyone who comes in, whatever is available, and turns it into honest and magical meals. He’s probably Barcelona’s best kept secret - he’s not in any guide (which is a good thing), and I doubt he even has a license to do what he does.

He gives you whatever he has, and what he has is always excellent quality. He probably goes by the farmers and vineyards himself to select his products. No is not a word he accepts, and there’s no way you can eat everything he gives you.

I’m always a bit worried when I bring people there because it takes some time to get there, it’s always difficult to organize it, and you just never know how people will react, or how Angel will react if he happens to be in a less sociable mood and gets asked to cook something non-meaty for example. But I’ve just never been disappointed, so I don’t know why I worry.

Today we went there to kick off our developer meeting now that everyone’s back from holidays and Julien, a new guy, just started. We got chorizo, manchego cheese, beans, a huge tortilla, a special Cabrales cheese which was very strong but good, bread, and duck pate. And those were just the starters, I had to explain to my surprised collagues. After that, we got blood sausage, cutlets, and hake. All of this with some wine, and desert and coffee at the end.

And when you get up and leave, you ask him for the price, and he makes one up on the spot for the whole group. Rumour has it it’s cheaper if you’re a girl and can part with some pecks on the cheek.

If you ever get to Barcelona, drop me a line for the address. And let me know if you write for a tour guide or travel magazine, so I can give you the wrong information. I don’t ever want to see it get ruined.

I have been looking for a new hosting option for a while and last week I finally choose one. Based on recommendations from others I ended up going with Slicehost. Slicehost advertise themselves as being a hosting company for developers, which I learned is definitely true. It is the first time ever I had a hosting setup where I even needed to install and configure my own email server. Learned a lot about Postfix over the last weekend

That said their setup is pretty nice. You can choose which linux distro you prefer from a quite big list and they will automatically set up your slice with that distro for you. They also have nice webtools for configuring things like DNS. And finally they got a lot of easy to follow tutorials on how to get common server tasks configured and running. Most of them Ubuntu centric, but I found it easy enough to find the Fedora equivalents when needed.

Once the basics was taken care of it was time for me to get my photo gallery back online after a longer period of being offline. Mostly due to me not having kept the gallery code up-to-date (and thus secure) it had been disabled at my old hosting provider. So upgrading to latest version was step one. The upgrade instructions turned out to not work at all, but doing a fresh install seemed to do the upgrade job just as well, it still managed to pick up all my old photos. I am still using Gallery 1.x though, but I noticed that Fedora packages Gallery 2. So I should probably switch to that at some point as having Fedora packagers make sure I am up to date without glaring security holes is more likely to work in the long run.

Anyway, to summarize a long story, my photos from GUADEC are now online

I also orderd myself an Epson 350 photo scanner today after discovering that <a href=”http://avasys.jp/hp/menu000000500/hpg000000442.htm”>Epson</a> actually provides official drivers for Linux. Hopefully I will soon also get all my pre-digital photos online.

Havoc,

I totally agree that embeddable languages is the way to go.  I’ve been using JavaScript heavily lately, along with the excellent Firebug for debugging (decent debuggers are something some very big languages are missing btw).  The biggest issue I have with JavaScript  is it’s lack of structure and horrendous scoping rules (this certainly doesn’t mean you are calling the containing object, especially when running a “method” from a callback).

What would really make JavaScript even more useful is the proposal for JavaScript 2. Unfortunately that presentation was made in 2006 but some, if not all of those features are part of the ECMA Script 4 proposal.  They even have a reference implementation up which is under a liberal license (I haven’t looked into it much but it links to a GPLv3 library).  As anything in committee, it is slow moving.  Hopefully we will see a finished spec sometime soon but I couldn’t find a timeline.

In the meantime there is an ECMAScript 4.0 to JavaScript converter call Mascara.  Unfortunately it is under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 license which means the code can not be distributed on many distributions because of the Noncommercial clause.  It isn’t always clear what constitutes commercial and most distributions I know of want to allow the possibility of for pay distribution or use in a commercial product by 3rd parties.  It also isn’t clear if that license extends to the generated code.  Does anyone want to write a GPL version?

Truthfully, I have a dirty little secret - I like JavaScript with all of its warts and hackish workarounds.  I like it because I know non-programmers who can grok JavaScript but can’t wrap their heads around Python or C.  I attribute that more to the environment than the language itself because it allows for the instant gratification of hitting the reload button and seeing something happen.  But what I like even more is the idea of embeddable languages bringing that sort of development process to GNOME.  There are a few apps that already do this and though it isn’t as easy as it is with the web whenever I have jumped into one of those apps, such as experimenting with writing a quick Vi mode for gEdit, it is amazingly simple.

What would keep me working in those environments would be an embeddable debugger, object viewer and UI/extension point tree.  Whoever writes those components and makes it simple to add scripting to any GObject app will be a hero in the community.  Anyone willing to sign up?

However, the wireless driver isn't integrated into the kernel yet, and the old driver tarball is already broken on 2.6.27 release candidates. I was having a hard time finding who was working on it or where the code was. So, I cobbled together the patches I found wandering around the internet, and put up a git repo:

git clone git://anongit.anholt.net/git/rt2860

Don't expect this repo to necessarily get updated, but it'll probably get you going if you're on 2.6.27-rc2 or so today.

Every time I have to write a spec file and do something specifically for a certain distro version (like, for example, packages were renamed or split or …) I end up trying to remember what the last package was in which I used it to have the most up-to-date version of that macro.

And once in a while I try one and it doesn’t work, for some silly reason. And these macros are always very fragile.

So, this weekend I rebuilt a package for RHEL5.2 and the spec was supposed to BuildRequire: libXv-devel for RHEL5 and onwards. But the check didn’t take the 5.2 version number (with a period) into account and it failed.

So this time I decided to just create a wiki page on my wiki that I will update if I ever run into problems again, and will reference back to next time I need it. In the process I managed to simplify the macros and make them more correct, so everyone wins. And that includes you - because now you can go there too if you care! *

* Of course, if you’re part of the 99.99999999% of people that doesn’t write spec files for fun or money, then you probably don’t!

Arek and I have spent the weekend working - it’s been so hard to get a block of continuous time to work on deploying a new version of our platform that I decided I would set aside a weekend for it to get started and convinced him to trade two working days for two weekend days. It’s the only time I’m guaranteed not to be interrupted by everyone else at the time.

We decided we wouldn’t actually discuss stuff, just get things done. Of course, Saturday ended up being nothing but discussing every possible topic. While it was exhausting for both of us, it seems it was unavoidable, even when we both were planning to avoid discussions. I did get to understand a bunch of things a lot better, so I spent Saturday night staying up too long and synthesising the discussions into things to do for the future.

Today, Sunday, was more productive - we’re advancing on the list of tasks still left to do. In the evening I agreed to meet up with Mariette and friends to go see a movie, and Arek went along.

I was actually pretty impressed with the movie. Arek thought it was artificial, which I can see, but I really like a well told story. I only found the basic premise artificial in the sense that I couldn’t believe someone would start out doing something like that.

There are two things I really like about the movie beyond the obvious (Philip Seymour Hoffman turns in another stellar performance).

A good piece of art makes you project your own ideas onto it, making you think that the piece of art is telling you something that in fact is coming from the other direction - you. In this particular case, I felt the movie showed what happens when a dysfunctional family dynamic, which is relatively harmless when kids are young, persists into adulthood. The same basic motivations and behaviours they had as kids bring on much bigger consequences when the now-adult kids have real lives and access to more powerful or dangerous resources.

You see this family interact in probably much the same way they did when the sons were kids - but the consequences of every action - stealing from your parents, harassing your little brother into doing your dirty work for you, stealing something from your older brother, fighting over a girl, whatever - are so much more far-reaching when the toy guns are real, when the money is more than what’s in a wallet, and when the girl is more than just yesterday’s crush.

Like I said, I’m probably projecting my thoughts on the movie.

The second thing I liked is how such a simple but clever premise births subsequent situations that are refreshing yet still entirely logical. The premise is so simple yet unbelievable that I’m surprised I haven’t seen it before in a movie - what would happen if two sons rob their parents’ store ? The rest of the story has its drama unfold in ways that you’ve probably not seen happen in the more standard thrillers, but it’s still predictable even in its originality. I can’t talk about any examples without giving plot away, though. But I very much appreciate how such a simple idea for a movie can be so powerful and basically write the whole movie on its own.

I understand what Arek doesn’t like about the movie, but I’m still pretty impressed - a good spur of the moment movie choice as far as they go.

I'm not a big fan of the Olympic Games, or maybe it's just that I don't care. I don't think I even followed what was going on -- except when reading some newspaper at the airport. But a friend of mine got annoyed that France wasn't really well-positioned in the medal count: we're currently ranked 11th or 7th, depending how you count things.

However, getting annoyed can lead to amusing results. He took the official results and made a script to compute the medal count for the European Union. And guess what? We're first, and with a large gap between the EU and the second country. Go see the true medal count :-)

After collecting some feedback and following some of the threads that have been started up, I've decided to do a second thought about my first proposal.

It had too much uncovered use cases, and still it didn't solved some major problems from the current one. To save some time and try to focus on the UI design issue, I decided to just do an inkscape mockup instead of a working solution.

This proposal tries to solve a few problems, and it's somehow inspired by gnome-specimen from uws. First, it gives an overview on how each style would  look like without the need to click on each of them, and it grants more space for the preview. It also adds a way to search for certain typeface classes, monospaced, language specific using a thunderbird like search box.

Some problems that I'm not sure how to solve here is, how to properly let people edit the preview text, I think that the entry box on top is fine, but I have the gut feeling that it could have problems. Also, I'm not sure how hard to implement the search box would be.

Anyway, feedback, again, is welcome.

Earlier today Richard and I did a DeviceKit (the set of projects replacing HAL) presentation for some other group here at Red Hat. You can see the slides here and here.

Perhaps of interest to the GNOME community, there’s also screenshots of Palimpsest, an upcoming Disk Utility library and application for GNOME. Most of this is already available in Fedora’s development branch, dubbed Rawhide, but won’t be installed by default in Fedora 10. Right now I’m busy with