Developing New Library for Icon Artists

Since I-don't-remember-when I have been making a complete rewrite of echo-aritst scrpits which are intended to ease the life of echo-icon artist - they create new icons from template, are able to add icons/symlinks to echo icon theme and add manage their local git repository. So they abstract most of the non-artist stuff away from the artist. During the rewrite I noticed several things.

• It would be usefull to split my efforts to backend (i.e. ruby library) and frontend. This would make it easier for me to change the frontend interface while keeping the functionality intact or improving the functionality without keeping the user interface intact. Also it makes the future possibility of writing a gui frontend much more viable.
• Also I realised, I could totally abstract echo specific stuff out of the library into the scripts and thus possibly make the library useful for non-echo icon artists as well.

I also decided to make a logical split of the originaly single methods into

• Icon related stuff - icon creation, icon rendering, icon checking if it has all requisities needed to successfully render it, handling icon symlinks
• Theme related stuff - generating completely new index.theme, automatic addition of new directories to already existant one
• Build System related stuff - creating symlinks when doing the things the old way, adding icons and additional symlinks to build sys when using autotools and icon-naming-utils, add symlinks when building completely from source (the buildsystem itself is done in a way that icons are added automagically), or creating a brand new buildsystem (supports only the one where we build from source ATM).
• SCM system stuff - currently it means handling git without the need for the user to know how to use git sans git push origin.

You can see the result of this split at the icon-artist documentation page and our git repo. Since it's my first time writing a ruby library and also my first time using rdoc I welcome any suggestions that would lead to making the library interface and documentation better ;-)

Now, back to the scripts. I believe ideal icon artist workflow would be like this:

• Create icon from template (echo-icon-create --context CONTEXT --template CUSTOM-TEMPLATE icon-name)
• Actually draw the icon in inkscape and label the scalable icon (in order for the scripts to know, which part of the one-cavas SVG is supposed to be the scalable SVG icon used in the actual theme)
• Add the icon to local git repo (echo-icon-add --symlink SYMLINK1 --symlink SYMLINK1 --branch BRANCH1 --branch BRANCH2 --component COMPONENT icon-file)

In addition to that you need to initialize your local repo at first (echo-git-setup), and at the current state of things you also need to update the repo before adding the icon (echo-git-update) and push your changes to fedorahosted (cd git-repo-dir && git push origin). So in order to achieve the above I need to add git update and git push to echo-icon-add script... Update should be OK and it haven't done it simply because I haven't actually though about it, the push is more tricky since unless I am sure it won't break things I don't want to autopush changes to fedorahosted. So it's possible I rather create a simple echo-git-publish script for that purpose for the time being...

What do you think of it?

On a related note, are there any ruby-fluent readers who could tell me if I am doing things right in this install script?

Echo Perspective Discussion

We're just staring final discussion about the base designs for Echo Icon Theme Perspective. If you can, you are welcome to either vote in fedora forum or join the discussion either in the fedora forum, at the fedora-art-list, or when I (msourada) am around, also on #fedora-art or #fedora-design on freenode.

Here are the desing concepts in question:

Fedora 10 and Multimedia - Is It Worse or Better?

Well, a hard question. At first I got thrilled by some new features, especially the automatic codec install, and pretty stable pace of improvements on gstreamer front, but lately I'm starting to notice issues as well.

First let me say that while both video and audio handling in gstreamer got generally improved I recently came across a clip (video in h264 and dual audio FLAC and mp3 in matroska + karaoke using styled ASS subs) that fails misserably pretty everywhere. Totem plays the audio fine, but the video gets pretty quickly out of sync, in gst-launch the video even eventually stops altogether. Gxine does not support styled subs, but other than that it plays it pretty well, though it picks wrong audio track. Mplayer plays it well, but the subtitles are totally out of sync. And that's probably the biggest woe of recent mplayer builds (where recent spans even to some time before Fedora 10 GA) - slightly more complex styled (ASS) subs are frequently out of sync or not displayed at all (usually when there are more subtitles at once).

So I was looking for a workaround using different video player, but... VLC a xine-lib don't support styled subtitles and for gstreamer there is a bug filled, with experimental plugin attached (using libass). So I've created packages for libass (it's built-in in mplayer, but I needed a standalone library) and for the gstreamer plugin (called assrender) and installed it. Yep, totem does not know about the new plugin for subtitles rendering, but after some googling and trying I sort-of learned how to make gst-launcher use it.

And well, though gst-launcher is good for debugging it's not good for playback, so I wanted to make a simple one-purpose media player using gstreamer and ruby (just for the fun of it :) But it seems, ruby bindings for gstreamer are not exactly in a state that makes it possible at the moment...

The assrender plugin, though highly experimental and not official, works pretty well and even support using fonts that are attached in matroska files (that's a really useful and pretty widely used), but because it supports only RGB colorspace output there are two colorspace conversions needed (YUV to RGB and back) which consumes cpu cycles and on my not so hi-end laptop it makes HD (1280p) videos, that are just about what my CPU is capable of, to fail miserably. So dear lazy web, if you want not-so-hard to do coding for gstreamer, you can help out with bringing libass support there. It would remove the last obstacle which prevents me from using gstreamer for everything ;-)

But at the same time, I am a bit concerned about mplayer as well - because on the same hardware, since Fedora Core 6 it's playback capabilities are getting steadilly worse. Not that it cannot play videos, but mplayer tends to fail resuming of paused video, then there's the issue with subtitles and lastly I've experienced a very weird bug (and workarounded it for my own purposes) - there's one assertion in ffmpeg code that prevents playing of certain matroska videos in mplayer.

Basically someone obviously expected that if you have chapters in a movie, than they will be strictly chronological, meaning next chapter (in list) won't start before current one. In matroska this is not always true and the failed assertion makes mplayer crash... For those who are interested, it's in libavformat/utils.c in compute_chapters_end () somewhere around line 1950 or 1960... It's this simple line:

assert(s->chapters[i]->start <= s->chapters[i+1]->start);

I'm still in doubts whether I should fill a bug or not about it... In my opinion there should be just if conditional, assert seems to me like an overkill, especially given that not aborting the code here (if the assertion fails) does not make mplayer doing things it is not expected to do.

My New Year's updates to Nodoka

Well, as nicu outlined in his latest webcomic we Fedorians are true geeks and so at New Year's Eve and New Year, I've coded with party and booze (actually I had quite a lot of tasty Chardonnay wine, though not enough to make my head ache the morning after)... well... the party and booze was at different time than the coding but that does not matter much...

So, what have I done? Not much, altough I'm slowly but steadily progressing towards the 0.8.x series of nodoka gtk engine. I wrote initial code for the check and radio buttons drawing in the three styles. Look at the screenshots and you'll guess pretty fast how far I am :)







Some sketches of the designs are available at nodoka branistorming page but I'd be happy to recieve more suggestions/comments regarding the new design :)

Well, and because it's New Year, I guess I could also add my "happy new year" to all my readers :-) This time in Japanese ＞＿＜