New Roxen Application Launcher for Linux written in Vala
A couple of weeks ago I stumbled upon a fairly new programming language named Vala. I thought it looked promising and since Vala is developed by the GNOME project – with the purpose of making software development for, primarily, GNOME easier – and I’m an avid GNOME user I wanted to look deeper into the world of Vala.
I, and most programmers I believe, work in that way that I need a real and useful project when learning a new programming language. So I thought why not re-writing the Roxen Application Launcher I wrote in C#/Mono a couple of years ago in Vala – which by the way is syntactically very, very similar to C# and Java. I’d gotten tired of always having to fiddle with the C# code with every new version of Mono since something always broke when Mono was updated so a re-write wasn’t going to be totally pointless. The good thing about Vala is that the Vala compiler generates C code and that’s what you compile the program from. Fast code and hopefully more mature and stable libraries that won’t break backwards compatibility with every new release.
What about Vala
So, on I went about it and I think that Vala is a really promising language. It’s still a very young language so some library bindings isn’t behaving exactly as expected and the documentation isn’t directly redundant – although the Vala reference documentation site isn’t half bad. But since Vala pretty much is a wrapper for, or binding to, the underlying C libraries you can find answers to your questions that way. All in all I think Vala has a promising future: Way more simple than C and almost as fast and light on memory (remember the Vala compiler generates C code) and way faster than C#/Mono and free from any Microsoft associations
.
What about the Roxen Application Launcher
In this new version I utilize GConf for storing application settings. I also made use of – for the first time – the GNU Build Tools for compilation which also makes it easier to distribute and for others to compile from the sources. This also means that the distributed version compiles from the C sources and not the Vala sources so there’s no need for the Vala compiler to build the program.
Other than that there’s nothing fancy about it. The Vala sources is available at my Github repository.
Roxen Appliction Launcher 0.4.2 19:38, Sun 20 December 2009 :: 374 kB
Screenshots
The screenshots is showing the Swedish translation.






Hi, while testing your new application launcher I ran into a bug.
It seems that when the AL GET’s an url which is moved (error 301) the software isn’t working. (function returns if http response status !== 200)
Error:
** (roxenlauncher:30068): WARNING **: launcherfile.vala:415: Bad status in download: 301
telnet tells me (when I GET the same url):
GET /bla/bla/bla.xml
HTTP/1.0 301 Redirect to secure server
Location: https://bla:443/bla/bla/bla.xml
Good work though! If I can get this app working it’ll be really useful to me
(there is no real alternative to the roxen launcher when using ubuntu 9.10, currently i’m using the old roxen launcher 2.2 with wine)
I think I pinpointed the problem,
your application does work when I use it in combination with a http:// server.. when the server is https:// it fails, returning the error described above.
Hope this helps you a little, I did not manage to fix it myself (yet)
now I see! https support is not yet implemented!
gio’s SocketClient() does not handle this, but I see libsoup has https support.
Cool, nice to get some feedback
I had problems with “libsoup” which totally scrambled binary data like images and such. Somewhere in GLib or libsoup some magic text encoding is happening. Thus I made my own HTTP client – a sloppy one that doesn’t handle redirects and other events
– where the data always is a byte array.
If I only can figure out how to make libsoup NOT encode/recode the data being transfered libsoup is definitely to prefer.
Thanks for the feedback though. Now I have something to do on New Years Eve since I’ve got the flu
BTW: I filed a “libsoup” bug in Vala and got a confirmation that there is a binding bug. The data in Soup.Message should be a “uint8[]” (which I have in my sloppy HTTP client
) and not a “string” as it is now.
https://bugzilla.gnome.org/show_bug.cgi?id=605862
As soon as this bug is fixed in Vala I will drop my HTTP client and implement a Soup client instead which then probably will resolv the issue with redirects and HTTPS.
I’ve fixed this bug in the last release: http://bit.ly/8vW9y5