Another release of CREATE shared resources will be done soon. I’m planning to add TRC curves to the spec and prepare a separate package of burningwell.org public domain hi-res textures. Yep — you get me right, shared resources will be modularized.

Short summary on other software related stuff:

• work on translation of Scribus’s docs into Russian has begun;
• I’m mentoring translation of XaraLX into Russian;
• hugin 0.6 has new docs browser, and v0.7 will have more docs both in English and Russian.

In early May I was in expedition to Caucasus. Had much fun shooting fake animals

Recently I compiled SVN build of Hydrogen — a cross platform open source drum machine. Hydrogen uses drumkits — libraries of drum samples that are usually stored in a local directory. SVN version features a network drumkits installator. It fetches updated list of available drumkits and lets users download new ones or remove existing ones.

What do you think about creating a similar online repository for shared resources and either internal or external clients to it? Internal client for each application means tighter integration, but also more work in common. External standalone-client means less work, but also less integration.

The most serious cons, I guess, is that this would clearly be installation into ~/.create and thus not efficient for multiuser desktops.

Subjects to further consideration:

• introducing modularization of shared resources (and thus having separate branches in repo for each kind of shared resource);
• introducing basic metadata for resources (name, description);
• organization of repository;
• administration of repository.

It looks like we are about to start working on another OpenDocument format for multilayered raster graphics. This is actually all about filling the gap. We have OMF and AES when it comes to exchanging audio projects, we have AAF when it comes to video. But there is no one uniform standard to store multiply layers, their compositing options, clipping paths, text on path etc.

When I say “we”, I mean developers from different projects. Several people independantly from each other were talking about very much the same at the same time. However, Boudewijn Rempt and Simon Budig were the guys pushed the magic button in this case

What is the point behind creating such a file format?

Imagine you have created a panorama project in Hugin. It’s fine except sun shone and hid again while you were shooting. Thus created panorama image will have lighter and darker vertical stripes then. Sure you would want to fix it. Logical would be exporting to some multilayered file format. Each of the layers would represent part or original image that went into the whole panorama and it would have an adjustment layers with curves over it. Then you would open it in some graphics editor and tweak adjustment layers. Which file format would you pick? The one that is supported by your favourite graphics editor, be it GIMP, Krita or Photoshop. A couple of years later when you might have switched to other editor you would probably like to be able to stll open that project file and tweak layers or something. You would like to be able to do it on just any OS and any graphics editor out there.

Or you are working on some design and you want to share it with other guys in the team who use other software than you.

The plan is to introduce a new OpenDocument file format. It ain’t easy thing. What you would await from such a file format, needs time to be implemented. Here is a basic list of features:

• full freely available documentation
• OpenDocument type of file format (archive with multiply files inside)
• storage of multiply layers
• storage of each layer’s coordinates
• storage of blending options for each layer
• storage of adjustment layers
• storage of layer effects
• storage of metadata using {XMP – Dublin Core – IPTC} tags
• possibility to store metadata tags per layer
• storage of EXIF tags
• all text data in Unicode (UTF-8 or UTF-16)
• storage of paths, clipping paths, text on path
• storage of raster data in different colorspaces (RGB, RGBA, CMYK, CIE L*a*b)
• storage of image data in both 8/16bit data modes

I hope that more developers take part in this project. Temporary working page is organised. However, we can have success only if developers of major applications (Krita, GIMP, Pixel, mtPaint and others) agree to collaborate. Currently Krita, Scribus and Pixel ones are known to wish to work together.

In the mean time �yvind Kolås has come up with a lite proposal for revised XCF file format.

Here is how it looks.

What is good? UI is simple. What is not so good? There is no way to edit more tags that are possibly available. You can’t tell if there is a “Year” field. And you can’t add a composer, if “Artist” represents only performer (classical music, jazz etc.).

So here is my simple proof-of-concept mockup:

I don’t claim to follow HIG in all aspects as of now. Here is just a concept how it should work.

The basic idea is that user usually knows better what ID3 fields/tags he needs to be present.

1. This dialog shows as many ID3 fields as the file has.
2. If you need to change some of them, simply edit the value to the right of the label representing name of that field.
3. If you need a new field, add it from a combobox, fill in the value and click “Add” button. A new row will appear above.
4. If no tags are present at all, start with a minimal default set of tags (Title, Artist, Genre) ready to be filled.
5. If more than X fields are present (with X like 6 or 7), vertical scrollbar appears to prevent the dialog from growing too high.
6. If you need to delete some field, click “Delete” button.
7. Once you added a new field, it cannot be used again. So combobox should “stay tuned” to what is happening above him.

This mockup was done basically with Audacity in mind. Remembering SoundJuicer, “Next Track” and “Previous Track” buttons should be added.

Another detail: whether amount of preset ID3 fields should be infinite or not. Probably developer should make a default set of fields/tags and let users edit it.

A default set of fields/tags would look like:

1. Title
2. Artist
3. Composer
4. Conductor
5. Album
6. Number of track
7. Year
8. Genre
9. License

Grab the tarball, use it, spread it, add support for the spec in your application if you are keen of standards (I dare to hope you are ). Currently Krita and Scribus developers have expressed interest to immediately add support. Other guys are a bit silent, but still patient

In other news: OpenIcc gets more and more weight. Just a week ago Adobe released their ICC profiles package as RPM following OpenIcc developers agreement on paths to search for profiles. And now F-Spot and Digikam developers seem to be going to support this initiative. C’mon, X.org guys, it’s your time!

So far, CREATE is moving forward. There is still no common decision on name of root directory, however.

To my excitement, after setting up SpamBlacklist extension on mediawiki we have much less issues with spammers.

Several interesting software project are about to release new code: Inkscape 0.43, Audacity 1.2.4 and 1.3.0, Hugin 0.5, Grisbi 0.5.8. And all of them except Inkscape require updated translation into Russian

Besides, Bulia claims to have ~120 Kbyte of diffs of new code in his local Inkscape development tree, which means that I should once again forget about using stable version of this awesome application