Autumn cleanup

It's been a while since I put anything here (whoaa, 5 months!) mainly because of personal issues I had during that time, which required my absence from the project and usual things.

So, I'm slowly getting back. Unfortunately, this absence period delayed planned EDE release and a bunch of stuff I planned to do in the mean time, and, for warming up practice, here comes small autumn project cleanup.

emountd, a small HAL abstraction routing daemon was removed. The main intent was to provide manageable way to receive events from various devices, without linking every program with libhal and required libraries. As usually, we got something worse as replacement; not even sure what exactly is today, systemd or some *Kit crap.

Because of that, planned mount listener (where you would get an icon on desktop when you mount some device) will be left for the future. Things are hairy now for anything normal and portable.

The second cleanup thing is documentation moving, better to say, overhaul. EDE 2.0 shipped with asciidoc, used to build application specific documentation and combine everything in EDE Manual. I modified it a bit to make it easier to automate from build process, but it requried a serious update: official asciidoc already progressed a bit, some python 2.x idioms were deprecated and more and more distributions are shipping python 3.x by default (asciidoc was written in python).

Thanks to awesome kraileth, EDE Wiki is much better now so why not to move documentation there? Everyone could edit it without repository access, which is the main point of one big fat manual: more eyes, better content.

EDE and FLTK talks on FOSDEM

I got a really nice chance to speak about EDE and FLTK on FOSDEM, in two separate talks.

Both talks, EDE related lighting talk and FLTK talk, are scheduled in Sunday; FLTK talk will be held in cross-desktop devroom.

See you there!

Another update

After some period of inactivity here, due various obligations and increased work on EDE, I'm putting a short list of completed changes; some of them are visible and some not.

First the biggest one: a big overhaul of window container inside panel (the place where window icons/buttons are hold). In previous iteration, every window list change, which is emitted by window manager, would trigger buttons cleanup and recreation; not very efficient because this would make many C++ new/delete calls.

Now, those calls were dramatically reduced by tracking window states and desktop position, outside window list received from window manager; this also fixes one bug that annoyed me for some time: when you would focus window by clicking on window titlebar, order of window buttons inside panel would be changed. This is probably pekwm optimization for faster access of top level windows.

The next one is tray icon removal fix: when you had a bunch of apps inside tray and after you did some manipulation with them (close app, reopen and such), tray would leave empty boxes around. No more ;)

jam, a tool for building EDE and edelib, is now bundled with edelib. Beside it is easier to install it on platforms where is not installed (just go to edelib/tools/jam and hit make && make install), it is much easier to fix issues in it and distribute those fixes; you always get updated version with fresh edelib release.

Also, the last but not least, EDE and edelib are updated to compile and work on OpenIndiana, a fork of OpenSolaris. I'm not sure why, but I always get warm feeling around Solaris-es, no matter if they aren't popular much these days.

Upcomming planned changes should be mostly related to EDE Manual transfer to wiki and adding configuration for panel.

Manual is quite incomplete and will be much easier to update it (and contribute with proofreading and fixes) on wiki. Also, this will make code lighter (bundled asciidoc will be removed) making default EDE non dependable on python; however, to build icon theme you will still need it, unless you are using official releases, where theme comes already prepared).

Panel configuration is must feature before 2.1 release because it is often requested feature. Some people would like any kind of configuration and some GUI frontend; I'll see how can be added without delaying release 2-3 months more.

Talk on T-DOSE

I will give a talk about EDE, tomorrow (Sunday), at T-DOSE so feel free to come if you are near by. Also I'll setup booth during conference days (Saturday and Sunday) where you can pick up some EDE related merchandise.

This post is coming a little bit late mainly due preparation and the time spent on trip to Eindhoven. By car ;)

Hello TinyCLOS

A couple of days ago, in edelib tree landed TinyCLOS, a CLOS-like object system for Scheme. I used original implementation and thanks to it's excellent design, I had to change only a couple of lines of code to adapt it.

The main reason for adding it was to stress Scheme interpreter with some serious code so it placed inside edelib test suite and is not installed with the rest of the library.

Truth to be told, I was surprised when TinyCLOS loaded for the first time. Within first runs, I manage to detect a few nasty bugs: two in Scheme functions (append and reverse) and one in interpreter garbage collector. Everything was corner case so ordinary code used by EDE would probably not catch it, but who knows.

Another surprise is startup time: loading TinyCLOS is dog slow and with a couple of tests, it will require almost 10 seconds to complete where around 7-8 seconds will be reserved for library load. That is brutal!

I haven't had enough time to look deeply what the cause is, but one of the reasons could be eager creation of primitive class objects (<class>, <boolean> and so on); the second reason is definitely a large number of GC calls. In both cases things can be improved, which I marked as TODO for upcoming time.

Exploring Desktop Objects #2

In the first part of this text, I explained a couple of reasons why I created edelib-dbus-explorer. In the mean time, this tool got a couple of quite handy features I will try to explain here.

IMHO one of the killer features of Common Lisp, Python or Clojure are docstrings. You write the code and document it at the same time; the documentation becames a part of code, meaning you can easily get it at any point: from REPL or from some GUI fronted.

That is why I added docstring support in edelib-script (based on tinyscheme), so:

(define (foo a b)
  (+ a b))

you can write as:

(defun foo (a b)
  "This is foo function."
  (+ a b))

Yes, it is quite Common Lisp-like, but to avoid messing with interpreter internals and to leave some room for turning off docstring collection in case of optimizations, I put it as defun macro. Maybe I could use different name to reduce confusion, like s7 which uses define*, but I'm not going to bother with that right now.

Now imagine in similar fashion you can document DBus methods or signals. This feature would be extremely useful for tools like edelib-dbus-explorer which, for example, could display method/signal prototype and description as tooltip when user hovers over the name.

Actually this was implemented in edelib-dbus-explorer from the start, but without descriptions, as DBus does not have official way how methods and signals should be documented. However, searching through the various implementations, I noticed EggDBus and GDBus can provide them via annotations. Then I became extremely happy, meaning edelib-dbus-explorer got immediate support for them.

Since both EggDBus and GDBus put docstrings in different namespaces (but ends them with DocString), edelib-dbus-explorer will simply scan for annotations whose names ends with .DocString and pick the value. With this, I don't have to change it when I extend edelib DBus binding to generate introspections with e.g. org.equinoxproject.DBus.DocString annotation name.

Unfortunately, not all (gtk+) applications uses this feature yet, and the worst of all, this will not work with Qt applications. I'm not sure what is official way from Qt/KDE standpoint, but I noticed some of projects are using <tp:docstring> tag inside introspection xml for documentation. I'm not sure even if it is transmitted to DBus server or is stripped when binding tool is creating source code from introspection xml. This needs further investigation.

Beside of this, I added builtin help (you can invoke it by evaluating (help) function) where are described common functions and how is done mapping between DBus and Scheme types. I didn't have enough time to explain it briefly in previous post, so it gets deserved space now.

Tinyscheme (thus edelib-script) is a R5RS based implementation and as most of Scheme implementations have a few object types: string, number, list, vector and some of them hashmaps. Opposite to this, DBus have much richer types and is quite strict about them: if method call expects variable with int32 type, it will refuse to be called with int16 type. Which can be a problem as Scheme does not have notion of 32-bit or 16-bit integers; it only understaind number which is often largest possible integer (sometimes even seen in bignum form).

So I added type hints, inspired from Emacs DBus hints: int16 is represented as :int16, string as :string and so on. All hints must be added to method or signal call arguments if that call requires arguments. For example, dbus-call will call DBus method and using hints it can look like:

(dbus-call "org.foo.baz" "/org/foo/baz" "org.foo.Interface" "Method"
           :string "Some string"
           :uint32 3)

where the first 4 parameters are service name, object path, interface and method. Things gets complicated when we have DBus complex types (like array or struct), but thanks to Scheme/LISP lists, these problems are easy to overcome. So, to represent an array of 4 uint16 types, this is used:

'(:array (:uint16 1 :uint16 2 :uint16 3 :uint16 4))

I know, it is messy, so I cooked a function called dbus-make-array that will simplify this like:

(dbus-make-array :uint16 1 2 3 4)

On other hand, DBus struct type behaves much like C/C++ structs and can have many different types inside own collection, much like Scheme lists. Unfortunately, you still needs to explicitly add types, like:

'(:struct (:uint16 1
           :string "Foo"
           :object-path "/org/baz"))

Dictionaries are list of lists, where the first element is key and the second is value; both again must have types:

'(:dict (:string "key1" :bool 1)
        (:string "key2" :bool 0))

And any of these can be a part of each other, creating even more complex combinations. Truth to be told, from syntax stand of point, things can be improved, but it is all matter of creating additional functions or macros. For example, we can simplify struct syntax like:

(make-struct :uint16 1
             :string "Foo"
             :object-path "/org/baz")

I didn't cover other supported types, like Variant or ObjectPath and I'm leaving documentations to do that. However, one thing I would like to mention is the plan to add support for implicit conversion; for example, all positive Scheme numbers could be uint32 type and the negative int32. This would make typing and overall things much easier.

Anyway, since video speaks more than thousand images, here is a small demo of the main edelib-dbus-explorer features in usage. If you would like to get hands on it, you will need to download edelib svn source code and compile it.

Feel free to ping me if you find some issues :)

Taskbar Icons Fix

When the new taskbar applet landed in ede-panel, application icons were fetched in pretty standard way: inspect _NET_WM_ICON hint and decode image data, if application set it.

However, I overlooked one major feature of mentioned _NET_WM_ICON: this hint can support multiple icons (by different sizes), and modern GUI applications are starting to use it extensively. I added support for this in one of recent commits.

What are benefits of this? First of all, take a look at the provided picture:

The first image is natural sized (16x16) provided by application and the second one is explicitly scaled, which was done until now. So beside cleaner icon look, we saved a couple of CPU cycles that would be wasted for unneeded scaling.

Exploring Desktop Objects #1

Recently I played a little bit with Pharo (which is a fork of Squeak Smalltalk) and I was quite impressed with it. Since this was my first connection with Smalltalk, the language simplicity and clarity struck me hard, wondering why we are still living in dark ages of C++/Java or whatever language that is daring to call itself Object Oriented.

A perfect companion for this language comes in form of it's own environment: you have a full desktop under single executable which isn't desktop in a normal sense: it is much more like environment of objects, where everything you touch and move (window, button) is a true object.

Of course, every sane GUI C++ program will use object notation for buttons or windows, but at the end, they are compiled down to assembly and you are done with it. To have a false sense of ability to change it, you would modify some configuration files, reread them and load the program again.

With Smalltalk is different: if you want to change how button looks in certain window, you just get it's object and call whatever method you can call (in Smalltalk parlance: you send a message). Or, if you, at some point would like to see how this window is written, you simply query it's source code.

If you are still not convinced, check these videos from Alan Kay's Etech Presentation. Remember that was 2003 and we still can't do many of those things with (insert your favorite language here), no matter how fancy it is.

But, this article is not about how Smalltalk is glorious but what can be done to improve current situation. And some things can be done indeed, even if we are still living in stone age of modern languages (sic).

Now lets go to the matter.

Today modern way to communicate between desktop components and applications is DBus so situation here is very much status quo. DBus became stable, everyone use it and everyone is happy.

DBus brings notation of object paths, interfaces and methods; you can see object paths as instances living in certain namespace, which is pretty neat since you will have a lot objects floating around.

So DBus is very much object oriented, but why we are still have stone age tools to handle it? I'm not counting here language bindings (where btw. some of them are awesome), but the tools for exploring current objects (or object paths) and their context. Let we see what we have:

• standard tools shipped with dbus (dbus-monitor and dbus-send): well unless you know how to manually encode the message with array of strings or, for God sake, struct of arrays and dictionaries, you have to look somewhere else
• qdbusviewer and qdbus: much better, comes with Qt. Even qdbusviewer will popup a dialog to fill method arguments when you are going to call that method. However, services which do not have introspection data will make it unresponsive (you will need to restart it). Setting complex parameters (like arrays or dictionaries) is not possible.
• DBus Explorer: never tried it, but C#/Mono background decided for me to never try it; I don't have mono installed and not planning to do so.

How about some tool with exploring ability and ability to write and call custom code from the same place? Or maybe to have some IDE capabilities like generating code or displaying documentation of selected methods? Unless you are going to write it, there isn't one.

Why this matters when we have nice language bindings and even better archaic tools like dbus-send?

Well, let suppose you are going to write a client for PackageKit, but your language doesn't have ability to integrate packagekit-glib2 (or it was packagekit-glib :P) or simply, you don't want to add another library as dependency?

In that case, the only solution is to read reference api where you will get lost in a matter of seconds. Who needs examples when all methods are nicely documented and colored. What to call in which order? Well, either read the code or use dbus-monitor.

With the same approach applied above, if you are going to write your console http client (for example), you would either have to consult firefox source code or use wireshark to decipher http protocol. C'mon people, we are not living in '90-ties any more; we are lazy today and we prefer to see examples first.

Or, let put PackageKit aside (as we don't write package management tools every day). How about to see what (DBus) services we have on our system, which interfaces and objects they exposes? Or simply, your program exposes services; how the hell you are going to test it? Again, you will use either dbus-send or write some testing code with python/ruby/etc. (before that make sure to download all their dependencies as their developers like to depend on as much libraries as possible).

So to make situation in this field less painful as possible, the last couple of days I was working on edelib-dbus-explorer (it comes with edelib from svn). With it, I was trying to address above issues that itched me for some time.

edelib-dbus-explorer (as you can see from the shot) looks much like qdbusviewer, in layout form, but adds scheme interpreter as the main communication point (or better say edelib-script, which is nicely packaged tinyscheme with a bunch of addons).

In a Smalltalk fashion, you explore services and objects, find some method and hit 'Send to editor': you will get a code snippet ready for evaluation. Then, you continue to write some more code, add another method call and at the end, save everything. Could it be more complicated?

edelib-dbus-explorer recognizes almost all DBus types (except signatures and file descriptors); return values will be converted to scheme objects (simple types to corresponding scheme values, like DBUS_STRING to string and complex to lists, or list of lists like dictionaries). For input types (those that serves as arguments to method calls), explicit type designation must be appended as DBus is picky if you use uint32 or int16 because signature is different.

But, explicit typing is not an issue: when is instructed to generate code, all types will be correctly placed with added REPLACE_ME placeholder, which must be replaced with appropriate values. Hitting Shift-TAB will jump between those placeholders.

Is this better than previous solutions? I'm confident it is and can be even better, which adds more room for improvements.

to be continued...

Hello notifications

During these slow preparations for 2.0 release, I figure out how EDE does not have any kind of notification service, where applications could report custom statuses.

I'm using Fedora Xfce Spin, where I replaced Xfce with EDE and recently I removed all Xfce applications and libraries from the system. This affected Xfce custom notification daemon which displayed various infos (e.g. firefox download status, VirtualBox driver update and such). AFAIK, more and more apps are using this notification specification which is good.

So here it is, with humble name: ede-notify-daemon. It support important parts of the spec, where the rest I will leave for upcoming versions. Truth to be told, I will (probably) never implemented full specification as it badly complicate simple thing as displaying notifications. I'm wondering are those GNOME/KDE guys come up with anything simple or we will at the end start to roll (again) own solutions?

There is no configuration options for ede-notify-daemon; this is planned to be done in 2.1 release.

Small panel enhacements

With last couple of commits, panel got two small enhancements: variable width and hiding capability.

Setting custom panel width was feature requested long time ago for eworkpanel in EDE 1.x. I'm not sure why but people likes it, although I'm getting feeling something is missing when I'm not having fully stretched panel. But, we should not discuss about personal preferences...

As everybody likes screenshots, here it is:

Check the gallery for full size, as I wasn't able to find sane way to link smaller thumbnails on bigger images.

The background is taken from Desomnis gallery; she kindly allowed me to to use couple of images as wallpapers and distribute them with EDE package. Nice example in murky art world, where IMHO they are quite behind with their licenses (comparing to GPL, BSD, etc.) and do-not-use-until-I-allow-it attitude.

The second enhancement is addition of small button (I called it hider) for explicit panel hiding. I always liked this feature in older KDE/GNOME versions, which sadly gone over the time. Autohide is nice feature (which by the way is not implemented yet), but I find it more annoying than usable: panel is hidden, you accidentally move mouse to the bottom and it pops out, then wait to hide itself again... I like more explicit things: when I hide it, let it stay hidden until I decide to show it.

Again, personal preferences...

Just to note: there are issue when panel width is shrinked and clicked on hider; panel will not be able to be shown any more. This will be hopefully fixed soon.

Screen locking support

Well, I'm pleased to announce two, small, but excited news: my ssh account for equinox-project.org was restored (yea!) and screen locking support was added.

Screen locker is actually a small shell wrapper (called ede-screen-lock) around xscreensaver and/or xlock and will choose one, depending on whether or not is one of them installed. If you have another locker you consider is more popular (I'm a bit behind recent changes in desktop world), please drop me a note.

Why I'm so excited around this small addon? Well, it is the first (user visible) change after more than a half year. In the mean time, I did a lot of changes in backend code, mostly related to new scheme dialect called edelib-script (used in still experimental theme engine) I will write more about it in one of upcoming posts.

The next major todo is to focus on updating and refreshing EDE web page and starting wiki server. Also to mention, I created and setup alternative domain, http://edeproject.org, which will point you back to http://equinox-project.org; edeproject.org seems to me much shorter and leaner, but equinox-project.org is what we get used to, so it will be here for long time.

No more eFLTK

In the last month there has been a lot of changes in repository. First of all, maybe the most interesting change is that edewm (window manager) was replaced with pekwm, making EDE now fully eFLTK free! This is the major step we headed to in last few years when decided to abandon eFLTK and fully focus on stable (and more maintable) FLTK 1.x.

I chose pekwm simply because it depends only on C++ compiler and X11 libs. I used it (and still using it) heavily with other EDE parts and it works without any major problems. Also, quite important thing for window manager was to have good window manager specification support, so users can replace them without any hassle.

Thanks to ChristTrekker suggestion I played with FLTK based awflwm, but it is still quite behind EDE needs.

Also, important news is how panel (ede-panel) got system tray support (implementing almost full system tray specification, excluding messaging part). This removed one huge limitation for current EDE usage, as more and more applications (and daemons) store own status in tray. Here is image with some apps running on Fedora 15:

There could be some issues I missed, but this thing is working and I'm using it daily (with skype and pidgin of course :)).

ede-launch got some important addition in form of support for preferred applications. This introduced new tool, called ede-preferred-applications from where user can select preferred web browser or terminal. I'm sure you already seen it in form of exo-preferred-applications from Xfce or similar tool from GNOME.

Basically, with this you will be able to run preselected terminal or browser, or simply leave ede-launch to guess your input and deduce what to run.

ede-launch can now directly run .desktop files too, which will simplify some code in ede-desktop component.

So to summarize, you can do this:

ede-launch http://www.google.com  # run selected browser
ede-launch foo@foo.com # run selected mail client
ede-launch --launch terminal ls -la /  # list directory in preferred terminal

As ede-launch is used to start almost everything, these features will become quite handy.

What are the major things left to be done before release? There is a small issue with long long support on FreeBSD's Xorg distro (EDE is compiled with -pedantic support yielding error reports when long long is detected, as it is not supported by C++ standard) and iconv inside pekwm (also on FreeBSD) that needs to be resolved. Also, I would like to review translation support and add intltool for easier string extraction from files that are not source code (conf and .desktop files, theme sources and such).

Memory applet and more

Few days ago I pushed a new applet that will show memory and swap usage.

The shot is above; noting smart behind it, but can be usable especially if you use firefox often or have Fedora/Ubuntu with tons of background processes ;)

edelib got facelifing in debug facility, inspired with debug functions and macros from glib. Previously, debug functions would simply write filename/line/text combination, without knowing from which application is emitted, like:

src/Window.cpp:53: loading 'edeneu' theme

Things become pretty messy when you get a bunch of reports from various place: edelib, ede-desktop, configuraion program(s) and etc. By introducting E_DEBUG_DOMAIN, which is set in compile phase, things looks like this:

[edelib] src/Window.cpp:53: loading 'edeneu' theme
[ede-conf] ede-conf/ede-conf.cpp:105: Can't load config

(of course the last line is pretty descriptive, but things got from edelib aren't obvious)

Also, things related to web hosting are still on hold. I contacted Csoft (as suggested by anonymous in previous post comments), but I'm still waiting for reply. Not sure how can I rely on these guys if I need to wait almost a month for a simple answer...

Web page is down

equinox-project.org is down; seems like the company that hosted our pages went out of business (Sohlius). Unfortunately all pages, including wiki and bugzilla, are inaccessible.

I tried to speak with LiquidWeb guys, as Sohlius contact is not replying, but without success. Sohlius was serving sites from LiquidWeb servers and this was naturaly next step.

Until someone from Sohlius does not contact them, our data would remain inaccessible. So sad.

I will try to setup some temporary pages until find some better solution, or get some reply from Sohlius crew.

Still Still rollin

Wow, looking backward, the similar post was almost a year ago. And it was like yesterday :)

Yep, the same working place as year ago, and a bunch of new technologies learned in the mean time. But, I'm still missing that rustiness of C++ and jam-s bug-ability, as I'm now in ruby/java/enterprise land where optimization means nothing and every slow-iness is rewarded with more RAM or disk. Looks like the world is going in different direction.

I'm not sure are you familiar, but EDE in some parts uses TinyScheme. Actually, except some playground, tinyscheme (all lowercase, easier to type) is used to describe schemes/themes, although there are few bits left to be completed. Still not sure about language choice, but believe me, I went through all 'modern' languages and still can't get that warm code-is-data feeling I'm getting from scheme (or any other Lisp).

The reason I'm mentioning tinyscheme is how recently was quietly released 1.40 version. The release have a few my patches, including one new feature hardly found in other scheme implementations: error line report in parsing phase. This becomes quite handy when the source grow over 10 lines ;)

Also, I must mention how I received a wonderful patch from Damon, still pending to add on repo. It gives ability to configure ede-panel, something I never manage to finish. Damon, sorry for taking too long to merge it, but I didn't forget about it. Thank you again!

Ahem...

Check this excerpt from one (very similar) project description I stumbled upon (project name is replaced with XYZ, but astute reader will easily figure it's name):

... XYZ is designed for cloud networks such as local freifunk clouds or the global Internet cloud. It can be built on top of various Linux distributions such as Ubuntu or Debian. It provides a fast desktop experience connecting easily with applications in the cloud and supports a wealth of programs, that can be installed with Linux systems locally. ...

Looks like I'll have to find some manager to write a few words on EDE wiki :P

Still rollin

Huh boy, I noticed the last post is old more than a month ago; the time is passing for me recently much faster than usually.

Probably the main reason for this is my new job, and some time I need to get used to new environment, people, workflow and the rest of the package that comes with it. As consequence, I had to shutdown (hopefully only temporarily) build farm, as build computers were hosted in facility owned my previous employee.

Other than that, I finally installed 64-bit Slackware 13, which I planned to do for some time. Maybe the main reason for this was to see how EDE will work on pure 64-bit platform; personally, 32-bit, 64-bit, they are all the same for me, except additional burden to learn assembler for different architecture (it is always good to know some asm when you do gdb beyond dumping simple backtrace).

Unexpectedly (duh!), I found problems in EDE code, both compiling and working. Compiling errors were mostly caused by newer gcc (due stdarg changes in glibc) and (as usually) PIC flag(s) for library creation.

Working errors were caused by some pointer magic (as expected) and my wrong assumption how WM property data is stored as CARD32 type. Other than this, I didn't find other 64bit specific issues, although this statement should be taken with some caution :)

Also, I added application icon support in ede-panel, as shown in the screenshot below.


This was (and still is) a quick hack and will be in some future stored in edelib, so the code can be used, for example, to show application icon in tooltip or pager.

Clock applet got some tiny refreshing with flat box and tooltip showing current date, like:


AFAIK this behavior is copied by others, so why EDE should be exception ;) Joke aside, this is pretty useful thing; for example I often forget current date and do not want to start ede-datetime just to check what day or weekday today is.

Translations and locale #2

Did you know that there is no generic tool to extract translation strings from non source files (anything else not related to some programming language, like .desktop files)? Neither did I, until I tried to find one.

Yes, I know about Intltool, but it is too much tied to Automake that makes it pretty cumbersome outside of it. In README, there is short how-to about Intltool usage outside autotools, but the solution simply cries for something better.

Now, taking into account how Intltool is mostly used by default from autotool users, I checked what autotool non-users has to say about this problem, primarly focusing on KDE, as they are using CMake.

Yes, they have solution and is not intltool, but after seeing it, intltool seems to me as the best choice I can get. Besides a full python framework dedicated to this problem, they have a help from cron script that nightly (or at some part of day or week) walks over repository merging and updating translations in .desktop files and presumably, documentation and other like files.

100 heads are smarter than one, but why this (their) solution looks to me pretty cumbersome? I mean, why someone couldn't made something that rest of the world can use, no matter are utilized make, cmake, scons or jam? Clearly, translation problem is not simple as it looks like.

The clear example was/is bad state about general translation are tools we had before. Not counting GUI frontends (like KBabel) which are mostly copies in different toolkits, solutions in form of web frontends (or for God sake anything else smarter than just calling xgettext in background) we only had in form of Pootle project, famous for it's slowness and memory usage.

Now you know why I see (and presumably others) Transifex project as gift from gods. Count to that free service they put on transifex.net for your project and we, users and developers, could not be happier.

But Transifex is still frontend... if we are going to find the root of this problem, maybe we should start from gettext tools. Hell, even xgettext (part of gettext chain) has differences between GNU and OpenSolaris version (presumably the same is for other Solaris-es). Sun version of xgettext is so dumb you can't even specify extraction keyword, so you must use 'gettext' instead e.g. '_' tag we are used to.

On other hand, GNU xgettext is no perfect either: it tries to be smart where it should be dumb. GNU xgettext can recognize programming language of source it scans and can extract translation strings in the way is best in that language. But, sometimes you want different things.

Recently I tried to add translation feature to theming engine in edelib, which includes some Scheme code, inspired with translation tags found in GIMP. Basically I wanted it looks like this:

 (display _"This text will be translated")

but GNU people visualized how things should be in more lispy like:

 (display (_ "This text will be translated"))

so there is no way you can force xgettext to see the first example as valid scheme source code without hackery with sed and shell.

Count to that how Intltool (which uses xgettext) does the same job as xgettext (extract strings from source code), but in own specific way, you simply lose any desire to do anything related to translation in your project.

Translations and locale

Aside from my busyness with daily job (and messing with ede-scriptbus to make something usable from it), there happened some changes in edelib too. Thanks to Thierry, locale bug and some installation issues in edelib are fixed now.

That was also a perfect time to finally do something about translation stuff in edelib and complete build scripts to install translated files.

I also created EDE related page on Transifex; for now online translation is not possible yet as I have to finalize and adapt translation facility in ede module. Facility exists, but I want to keep it in similar manner as in edelib (have po folders instead locale and store translation template in file named as application, instead messages.pot).

X11 Cursor Themes

On Arch wiki is a really nice tutorial how to setup custom X11 cursor theme. The good thing is how solution is pretty desktop/wm neutral, so it works under EDE as charm.

I found Chameleon theme very nice; you also get three different sizes: large, medium and small. Neat!

Following above wiki tutorial, I would add how using "~/.icons/default/index.theme" is probably the best solution. You don't have to mess with "~/.Xdefaults", nor need to have permissions to play with "/usr/share/icons" folder.

After you populate "~/.icons/default/index.theme", X11 will instantly load selected cursor theme. The only thing I found are often crashes, originating from libXcursor library. This could be either from graphic driver (nVidia of course) or from older X-es I'm currently running (time to upgrade it).