Although the previous release, using GTK3, came quite recently this release has some new things.
GSettings
I dumped the “keyfile” solution for the application settings in favour to GSettings. So the settings is no longer stored in a file in the application directory but rather in the system’s application settings backend. GSettings is part of GIO – the GNOME networking library – and since RAL depends on GIO no new dependency is needed. The upside is that I could put a file of source code in the bin! Plus, it’s fun learning new stuff!
Editors and content types
Previously I have kept an editor – name and command line – for every content type. Anders at Roxen thought it’d be better if editors and content types were separated. I’ve thought about that before but never bothered to do anything about it.
But now, along with GTK3, there’s a new (I think) AppInfo class and the new AppChooserButton and AppChooserDialog widgets so I thought it’d be cool to use those. So selecting an editor for a new content type is way more simple now, and it also looks nicer. Plus we get the icon for the editor in the content type list under the “Applications” tab
Simple logging
I also implemented some simple logging which can be viewed under the new “Logging” tab. This will be worked upon and at the moment not very useful information is written to the log, but at least it’s a start.
Default icons
The icons in the notification popup – which only are three to the number – is now fetched from the user’s default icon theme. They we’re bundled before.
SOUP all the way
Previously I have used a little hack for saving downloaded files to disk. The problem was that the Vapi bindings for libsoup casted the data to a string which totally scrambled binary content like images and such. My solution was to write a simple C-function which took a SoupMessageBody struct as argument and then wrote that to diskt always keeping the uint8[] type of the content.
I bug reported this way back and it’s now fixed in Vala so I dumped my solution and am now using Vala all the way. Gone is one C and one Vapi file.
While at it I changed from using blocking functions in libsoup to the async ones. You never really noticed blocking calls was used before, but right is right. Right?
I have updated the application launcher to use GTK3 so that it builds on Ubuntu 11.10 and any other Linux distribution using GTK3. This also made it possible to drop the dependency for libunique since Gtk.Application can handle single instance applications.
I also fixed a bug which made it impossible to use the appliction launcher on sites not running on port 80 or 443.
No big news, but the GTK+ tree view of files is now sortable. The “minimize to tray” function is now actually invoked when the window is minimized rather than closed. A right click in the file list now also let you go the the file’s directory in the Sitebuilder.
Also fixed a bug where the locales didn’t get installed correctly and also fixed a bug which scrambled the configuration file a bit.
This is not the latest version of Roxen Application Launcher. You'll find the latest version at the download page.
In this release of Roxen Application Launcher (come again?) for Linux I’ve gotten rid of a few dependencies, namely: gconf, libgee and libgnome. The reason I dumped gconf and libgnome was to make it easier to install in KDE. I’ve verified it installs in KDE, although I noticed the translation doesn’t work and the Roxen SVG logo doesn’t show up in the window top border.
Roxen Application Launcher in KDE
Libgee is a collections API written in Vala and since I used a newer version than what is available in most package managers, and I’m not sure all Linux distros provide libgee, I decided to dump it and implement the same functionality with the generic collection classes in Vala. And since the collections used in RAL is quite simple that worked out just fine.
I have also tried to implement bundled download, which is only used in Roxen Editorial Portal. Since I don’t have access to such an installation I haven’t been able to verify it works as expected. I re-implemented the same behavior as in the launcher written in Pike by the Roxen guys.
Oh, and if you already have an installation of my RAL your previously downloaded files and settings will not be available to the new install. Since I dumped gconf I now store the settings in a plain text file and I have put the RAL application directory in ~/.conf/roxenlauncher since ~/.conf is where you should put application specific data according to freedesktop.org. In previous versions of RAL I stored application data in ~/.roxenlauncher so if you want your previously downloaded files copy ~/.roxenlauncher/files to ~/.conf/roxenlauncher/files.
This is not the latest version of Roxen Application Launcher. You'll find the latest version at the download page.
So I had a go at the Roxen Application Launcher (come again?) for Linux. I added a context menu – when you right click – to the file list. When you right click a file in the list you get the option to view that file in the Sitebuilder, edit it or remove it.
Other than that there’s nothing new. And since the application seems to be very stable I decided to bump the version number to 1.0.
Twingly is a blog search engine that focus on indexing the “blogosphere” rather than being a generic search engine. Twingly has a ping service that let you ping Twingly when you have new content on your blog so that Twingly can head over there and index the new content asap.
Since Roxen CMS have event hooks this module listens for newly published files and when found automatically notifies Twingly about it.
The only thing needed is to set up a config file in the SiteBuilder’s workarea so that this module knows under which paths newly published content should notify Twingly and with which arguments. But all this is documented in the module.
One note! If you run a replicated environment install this module on one of the frontend servers, not the backend. If installed on a backend Twingly might head over to your site before the new content has been replicated.
Nowadays web sites and web applications tend to be more and more JavaScript driven which results in humongous JavaScript files. It’s not uncommon to have several 100 of bytes of JavaScript on a site. Of course web browsers cache stuff like JavaScript so that it only is requested from the server once. But judging from the visitor logs at work most people only visit our site once a month or so which means that cache will expire and all those scripts has to be requested upon the first visit.
Now, there are several ways to compact JavaScripts: Packer, YUI Compressor, Shrink Safe, jsmin and many more. Some of these just remove redundant white space and comments, some obfuscates the code and shortens variable and function names and what not. Many of these scripts and programs are very fine but they require you to manually minify your scripts, and that’s just a hassle!
But since we use Roxen CMS at work things get much easier if you write your own Roxen filter module which automatically minifies JavaScripts on the fly, given they meet certain criteria. And so I did!
I ported the original jsmin code written in C to Pike. Then it was just a matter of creating a simple filter module for Roxen. And then it was all done.
You can use two criteria to determine if a script should be minified or not:
Path glob: In the module settings you can specify any number of directory globs or full paths. If a requested JavaScript either is in a directory matching a glob or is a direct match it will be minified.
Query string variable: In the module settings you can define a variable name that if exists as a query string variable in the request the JavaScript will be minified. So:
This is not the latest version of Roxen Application Launcher. You'll find the latest version at the download page.
Okey, here comes an update of my Roxen Application Launcher (come again?) for Linux.
There’s no major changes to this release. The connection to the Roxen server is now stored in a shared object so that it can use a “keep-alive” connection. Not that I think it matters a great deal.
There’s now an option to change the behavior of the applications window close button so that it hides the application to the tray – or notification area as it’s called in Gnome – rather than closes the application.
This is not the latest version of Roxen Application Launcher. You'll find the latest version at the download page.
So, here’s a new release of the Roxen Application Launcher for Linux (RAL). The previous versions used my home made (sloppy so) HTTP client which didn’t handle redirects or secure connections – thank you tec for the feed back – since I had some major problems getting libsoup working with binary files like images and such. Binary files was heavily scrambled when read from or written to disk so I made my own simple HTTP client that kept the data as a byte array to prevent some underlying libraries (GLib) from fiddling with it.
But I solved the libsoup issue so now the RAL handles redirects and secure connections. This is how I solved it:
The libsoup issue
When uploading a file back to the Roxen server I use IOChannel (g_io_channel in plain C) instead of Gio. So the upload works like this:
When downloading data it’s a bit more tricky! Of course I tried using IOChannel in this case also but that made no difference. Downloaded images ended up 4 bytes long! But then I thought: You can make your own C bindings in Vala (remember the Vala compiler generates C code) through what is called Vapi files. So what I did was writing a C function that takes a SoupMessageBody object/struct passed from Vala and writes the data part to a file given as argument.
message("The file was downloaded and written to disk OK");
}
else{
message("Failed writing data to disk!");
}
}
So that’s that on that!
The notification
I also – just for fun – implemented a notification mechanism through libnotify. Since I believe that can be rather annoying it’s not activated by default but can easily be activated by a checkbox in the user interface.
This is not the latest version of Roxen Application Launcher. You'll find the latest version at the download page.
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.
Although I’m working on some social web related Pike modules where a Gravatar module is included I needed a Gravatar module right now at work so I hacked up a standalone Gravatar Roxen module.
This is how it works
12 lines of RoXen Macro Language
<ul>
<emit source="sql" host="mydb"
query="SELECT name, email, `date`, body FROM my_comments"
I read an article on A List Apart about creating “A More Useful 404”. I also think that it’s important to give better feedback to the visitor who ends up on a missing page. But I think that the customized 404 page should differ remarkably from the original site layout so that there’s no doubt about you’ve ended up on a “missing” page. I’ve seen 404 pages that are impossible to tell apart from the site and it can take quite some time before you realize you’ve reached a dead end.
I’ve used a customized 404 page on our sites at work almost since day one. The feedback to the visitor can be better but I have an email function – like suggested in the article at A List Apart – that sends an email to me, telling which URL the visitor tried to access and which URL the visitor came from, when someone reaches a missing page from a link, internal or external.
And I must say that this function is really, really helpful. If the broken link is on another site I usually send them an email notifying them about the problem and giving them the correct link – sometimes you just need to re-structure your site, even though it should be avoided when possible – and mostly they appreciate it and alter their link immediately. Also, when re-structuring, it’s easy to miss a few of your own internal links and with the little email notification the problem can be fixed right away.
In Roxen (the CMS we use at work) terms, all that needs to be done is adding this little snippet to the 404 page template in the administration site, under the “settings” tab for the site in question.
So the Roxen User Conference has come to an end. It’s always nice to meet with people who speak the same “language” (the language of the geeks perhaps), to share experiences and solutions. And of course it was nice to see the Roxen Editorial Portal in action. That’s a pretty cool piece of web based software. It was also nice to get a preview of Roxen CMS 5.0. It will have a few new features that will be nice and perhaps the greatest thing is that it will incorporate Pike 7.8 (which in it self hasn’t been released yet).
Anyway! For me it was a great experience talking to other Roxen customers and share some ideas and views. Oh, and one more nice thing: during the conference Roxen released a community site – planet.roxen.com. I hope it will be a great resource for us Roxen customers and users.
Ok, so now the first day of Roxen User Conference is about to end. The has been some interesting speaks today and a few new acquaintances. The most impressive thing is to have see how different companies and institutions have implemented the Roxen platform. To me Roxen is not just a CMS but a great development platform and from my new experiences from all over the world today my conclusion is I’m not the only one with that standpoint.
Of course there’s been a few drinks (beer, wine, whiskey and what not) but also some new friends and faces to known names. And of course there’s also been some sharing of code concepts and what not.
Tomorrow there will be some more hands on workshops. Roxen will demo their new “Link management module” which will be part of the 5.0 release. It looks really promising from the previews we’ve seen today.
In the 5.0 release they will also bring to live a new patch module which will ease the maintenance of a Roxen empowered server park in a tremendous way. That feature will be awesome.
One cool thing in particular is to have seen a demo of the Roxen Editorial Portal. A few newspapers are already running it located from Sweden to USA to Australia. A really cool achievement for such a new product! You guys at Roxen rules!
So after five weeks of vacation I’m back at work. The most sensational thing must be that I didn’t write a single line of code in these five weeks! It was a much needed break from computers and the longest one I’ve had for the nine years or so I’ve been programming. The vacation it self isn’t much to talk about. I visited friends and family and spent a lot of time in the sofa watching the olympics – and playing some Play Station 3 as well
I also just bought an Asus EEE which I think is quite cool. I’m actually writing this blog post on it. I threw out the Xandros operating system and installed Ubuntu EEE instead which feels a great deal better. I’ve installed a lot of developer tools and they actually run rather smoothly.
Screen shot Ubuntu EEE
Roxen user conference
Next week, Thursday and Friday, I will attend the Roxen user conference which I’m really looking forward to. I’ll give a report from there when it happens.
I just created an updated version of Roxen Launcher. I got an error report from one who tried to build the application:
./ApplCon.cs(232,24): error CS0122:
‘System.Net.Sockets.TcpListener.Server’ is inaccessible due
to its protection level
An explanation of the error can be found at MSDN. The reason seems to be due to TcpListener.Server being a protected property but I tried to access it as public. The strange thing is that I didn’t get an error about it nor on my machine at home or at work. Now I created a derived class of TcpListener.Server so that I can access the protected property.
I thought I should broaden my C# knowledge a bit and you know how it is: To learn new stuff you need a real project to work on or else you will lose the fire sooner than later. So I came up with a good project that is actually useful to me: Porting Roxen’s “Application Launcher” to C#. There’s nothing wrong with the original one, written in Pike, except that it uses GTK 1 which is quite hideous (in an aesthetic meaning) compared to the newer GTK 2. And I also though it would be cool to create a panel applet (in the notification area of Gnome so you could put the Application Launcher in the background).
BTW: For those of you not knowing what the heck Roxen’s Application Launcher (AL here after) is here’s a brief explanation: Files in Roxen CMS is stored in a CVS file system which means that you don’t deal with files the way you normally do. To manage files you use a web browser interface (which is a darn good one I might add) but sometimes you actually want to edit files in your standard desktop application. And it is here the AL comes to play. You can download a file through the browser interface so that the file is opened in the AL. AL will then open the file in the desktop application you have associated with the file’s content-type. When you make your changes and saves them the AL will directly upload the changes to the server. So in short I could have said: The Application Launcher is a means to edit files on a remote Roxen server with a preferred desktop application.
The obstacles
I must say I’ve learned a lot from this project!
First off: If you download a file for editing and the AL is already started you don’t want to start a new instance of AL (this is something I have never ever thought about before – in general terms, not just concerning AL) but when you do think about it you find that it’s not a piece of cake to solve. I solved it the way it is solved in the original AL. The first instance of AL that is started also starts a “socket server” that listens for incoming traffic on a given port on the local IP. When a new instance is started it first checks if it can connect to said port and if it can it sends the arguments through the socket to the first instance which then handles the request. The second instance is simply terminated when it has send the data though the socket.
So there I had to do some socket programming. Great fun
Secondly: Stuff happens in the background of AL – data send through the socket remember – which means that nothing happens when you try to update the Graphical User Interface. (NOTE! This is the first more advanced desktop application I’ve done.) After “Google-ing” around a bit I came to know that this was a real newbie problem The thing is that the GUI can only be updated through the same thread that started it so when using background threads – implicitly that’s what I’m doing although handled by the asynchronous callback infrastructure of C# – you need to make sure the GUI is updated through the main thread. This is the most simple way so solve it:
3 lines of C#
Gtk.Application.Invoke(delegate{
CallFunctionToUpdateGUI();
});
That’s not too difficult when you know it
Thirdly: The AL is sending data back and forth through the HTTP protocol which means we have to use some sort of HTTP client. C# has a couple of ways to do this but unfortunately they came up short, or I couldn’t use them anyway. I didn’t manage to figure out exactly why I always caught an exception saying something like: A protocol violation occurred!. I’m far from the only one who have fought with this and it has something to do with the headers sent from the remote server. You can invoke “unsafe header parsing” but that was to much of a hassle so I created my own little HTTP client.
One big annoying thing with C# is that is seems almost impossible to turn data from streams into strings without having to use any one of the System.Text.Encoding.* classes/objects which in my case meant that images and files in binary form got seriously fucked up. I manged to solve this my never turning the data into a string but keeping it as a System.Text.Encoding.* all the way from request to response to saving to disk. It was rather irritating but at the same time nice when solved (and I learned a whole bunch about System.Text.Encoding.*, System.Text.Encoding.*, System.Text.Encoding.* and System.Text.Encoding.*.)
Finally: Of course I learned a great deal more about C# but this blog post is starting to get pretty excessive so I will round it off by saying that MonoDevelop is starting to become pretty darn good! I just upgraded to the latest version of Ubuntu and that also meant that I got the latest MonoDevelop and I must say it’s more stable than ever (although it occasionally crashes) and a whole bunch of new features are in place. One I havn’t used before – although it might have existed before – is the “Deployment” stuff. It creates a package with configure and make files for optimal compilation. Really smooth!
Source and screens
I will finish off by adding the source files and a few screen shots:
It’s amazing that I havn’t posted an entry here for more than six months! I’ve had so much to do at work so I havn’t had the driving force to bother! We’re about to release a redesign of www.tekniskaverken.se which have taken quite much time. We’re also about to update both the server hardware and software. We’re going to use Roxen replication and load balancing which means we’re going from one standalone server to three servers!
I’ve also been busy developing “My Pages” at Tekniska Verken where our customers can log on and view consumption statistics for water, district heating, electricity and waste and much more. The statistics part has existed for years but the functionality has been rewritten from scratch where webservices SOAP) for our business system has been developed and the overall functionality has been extended and improved.
The fun thing is that I have written the SOAP clients in Java – since Pike (the language used in Roxen) doesn’t have a SOAP implementation yet but do talk to Java quite nicely – which I’ve never touched before. Java is a nice language but the Classpath thing drives you crazy! Anyway, with WSDL and Eclipse there has been no problems. There’s currently 13 webservices available and I don’t think I’ve even written 2000 lines of Java to implement them. SOAP is really nice I must say! So now I also can add Java to my CV
Jonas Walldén, CTO at Roxen, has improved my RXML tag contribution <trim></trim>. The code is now really beautiful and you can tell the difference from the code written by a lamer, as myself, and a real programmer, as Jonas. Jonas told me that the <trim></trim> tag will be part of the next Roxen release
I also – just for fun – implemented a notification mechanism through 
