Welcome to my personal web page
When developing a C++ library that we later intend to provide by means of a Debian package, there are certain things that make it really complicated and hard to maintain. Everyone that had to deal with debian/symbols in a C++ library knows how troublesome it is. The biggest problem besides name mangling: symbols leakage. By default the GNU ELF linker exports everything as it goes, leading to maintenance hell. Sadly, this has to be dealt with on the source level - the best way? Symbol export maps.
Happy new year! I hope this post to be the last one in the series of 'Appmenu for Qt5'. Holidays have passed and now all my required patches have been successfully merged to upstream Qt repositiories. This means that according to our current policy, we can now cherry-pick those patches to the Qt5 versions that are used in Ubuntu. Therefore, the still-prepared Ubuntu Qt 5.2 packages are already shipping my changes as quilt patches, enabling proper appmenu-qt5 support. All is ready for testing.
Some time ago I mentioned working on the global application menu for Qt5 - the so-called appmenu-qt5 for Ubuntu and its derivatives. After a longer while, I finally fount the time and occasion to resume my work - and, after a really bumpy ride, end up with a working solution. Some hacks had to be made, some Qt5 design decisions worked-around - but the end result is here: a working appmenu-qt5 QPA platformtheme plugin. In this post I would like to overview the implementation of the current proposed appmenu-qt5. Read on if you're interested in some of the Qt5 internals, workings of QPlatformTheme plugins and the confusing elements of the Qt Platform Abstraction in overall.
I had an annoying problem today to which I finally found a workaround for. Let's assume we're using qmake and the 'testcase' CONFIG for a given target. Strangely, whenever the testcase configuration is used for a given project, all test targets are generated with their 'make install' targets in the Makefile (if the Makefile generator is used, of course). Even when we're not adding the target to INSTALLS. But what if we don't want to install the given testcase anywhere? Qt4 ant Qt5 docs say nothing. But the qmake source code says all.
All has been very busy lately, as managing the daily-release process and tools for Ubuntu proved being more challenging then we have expected. In the meantime though, I am also working on creating proper Ubuntu appmenu support for Qt5 by the use of the Qt Platform Abstraction (QPA) API. Not a hard task, but without proper time resources even this can be a bit troublesome. I would like to use this post to iterate some of the things that I have learned related to the Qt5 QPA topic, as well as mentioning some plans, concepts and remarks to proper Ubuntu appmenu support for Qt5, as designed by me.
Just a quick self-advertising update. Recently I have been involved in two fun activities: first, I wrote an article about Ubuntu Autopilot for the Ubuntu User magazine. It has been published in the 16'th issue of Ubuntu User. It's loosely based on the Autopilot for Unity blog post I wrote some time ago, just this time not only targeting the Unity system but also normal Qt/GTK+ applications. I have also been asked to give a short interview related to display servers and the recent announcement of Mir, for a polish computer-oriented blog - Morfiblog. It's polish-only, sadly.
Recently I have been working a lot on making IBus autopilot tests more reliable. The design was simple: fetch the expected resulting characters from IBus and compare those with what actually got written in the Unity Dash/HUD text entry. Simple, right? Wrong. IBus doesn't really allow you to just ask him: hey, when I give you the string "abc", what output string will I get for the current engine? You can do it if you explicitly use the input_context, ok. Hell starts when you want to use Python and the gi.repository IBus bindings (not the old python-ibus ones). Why? Because someone made some essential methods Introspectable="0" for no reason. But let's see how we can actually do without those. This post is a quick report from my battle with gobject-introspection of IBus in Python - with all my other trials and approaches. A lot of those!
ARM platforms were always important for the Ubuntu ecosystem - even more so since the start of the 13.04 cycle. For testing Unity on ARM I'm using an OMAP Pandaboard from the EA3 series. It's a very interesting platform to play with - quite powerful, high-level and good-looking! By no means it's a novelty, but something I have only recently got my hands on. Here's my really quick look on the Panda in my possession.
Unity currently uses a very interesting tool for functional testing: Autopilot. It's a custom solution created with Unity in mind, but can also be used for any other system as well. We have recently decided to start getting rid of all manual testing in Unity and related components, meaning no more running away from automated testing. This is a quick look on how we can use Autopilot to perform automatic testing for our convenience with the Unity stack. All related to Ubuntu 12.10 and later of course.
Parts of my latest interests tend to lean towards Android - both application and system development. There was one thing I noticed lately: whenever orientation changes, the activity gets restarted and might lose its state. This happens because Android has a strange policy of forcing the recreation of the activity whenever the configuration changes - such as orientation, language etc. So if we don't want our application starting off clean on every device tilt, well, we need to prepare it for this evil.
A beginners post today. The idea for this article came from my recent battles with packages and a question asked by a friend of mine - "how can I point where the system can find some private libraries of mine on GNU/Linux for my application?". There are a few methods for doing this: LD_LIBRARY_PATH, ld.so.conf and RPATH. A word of notice though - it is usually not wise to make your application depend on libraries in some private, normally unaccessible paths. But when you are forced to, here's what you can do.
It's really really busy on my side lately, especially since I got assigned to take care of some of release integration. That's why this time I'd like to write a bit less-technical post. I would like to share my experiences related to contributing to some of the official Ubuntu projects hosted on Launchpad. Ubuntu being first of all an open source community based system, most of its development happens due to contributions. It's really easy getting started! This might be considered as a pseudo-tutorial combined with a bit of soap-opera.
Sometimes, for whatever reasons, you might want/need to use an older cross-compilation toolchain for a given architecture, especially when you notice something wrong with the more recent versions. Ubuntu usually provides in its repository at least the two most recent toolchain versions. But switching to an older one is not that trivial, since another 'meta-package' handles creating of all the useful symlinks. Here's a hacky and blunt way of switching from one version to another.
In my yesterday's post, I over-viewed the situation of a fglrx-related bug in compiz that I have been working on recently. Today, after consultation with the developers from ATI and a joint bug-search with Sam Spilsbury, we were finally able to find the root cause of the issue - resulting in a one liner fix for a bug in compiz. So why did this bug only happen for fglrx? Easy. Due to implementation differences in the drivers.
I wanted to share a short story about an irritating bug I have been trying to fix in Ubuntu's compiz, related to the ATI Radeon proprietary closed driver fglrx. I had many context switches during the process, so it took longer than I suspected. This post might shed some light on a strangely specific problem that I encountered.
Today just a short post, glued together from a few small things that I found useful - more specifically, regarding deb-triggers and some old Plymouth bits. Anyway, geh, it's so busy lately...
A short post about something that's not really documented. When working on a communication application for Haiku, I needed to create a typical configuration wizard window. I required a few views to be present in one spot, with only one being shown at the same time - with the ability to switch between them on user Next/Prev button press. Since Haiku exports a neat layout API, I wanted to use one of those if only possible. And then I found the BCardLayout.
Come visit my Haiku Blog-O-Sphere page and read my new blog-entry - Bits and Pieces: The Small BCardLayout.
Quite recently I had the need and 'pleasure' of playing around with the Plymouth bootsplash. For those that don't know, Plymouth is an application which runs very early during the boot process and displays either textual or graphical boot animation, hiding the actual boot process in the background. There isn't much documentation available on the configuration and installation process - usually this is done by system distributors, not users themselves. As noted on the homepage, Plymouth isn't really designed to be built from source by end users. You can find some basic howto's around the internet, but today I would like to concentrate on the few bits that are harder to find.
Recently, I did some experimenting with the available OSK's (on-screen keyboards) around, ultimately focusing my attention on Maliit. Maliit is an OSK project mainly known for its use on the MeeGo mobile platform - but in reality it can also be used as an input method for both Qt and GTK+ standard applications on any Linux based operating system. Since the project is being actively developed and changes are made quite rapidly, a bit of work was needed to make it work for all possible IM cases. Nothing too complicated though. Let me help you dive in into the world of Maliit. Big thanks to all Maliit developers for their swift and professional help!
A modified kernel, a custom system - this can lead to the kernel not being able to boot properly. What to do in such case? Usually we can try getting as much information as possible to locate the underlying problem. We can use some quite basic techniques to achieve our goal.
Today's post is more private-life related than the others, but still in some means technical. I am proud to inform that I have officially joined the Canonical team as a Software Engineer! From now on, I will help enhancing the overall Ubuntu experience, mostly working on their flagship Unity environment.
Code profiling is a very important aspect of computer programming - almost every software engineer knows that well. It helps finding bottlenecks in your code, finding which parts need improvement, which cause trouble etc. I'm sure everyone knows of this already. There are many tools for this purpose available around the internet. This short post lists a few of them, as well as a brief introduction to a really simple and naive solution I made in the past.
During the weekends, I'm working on enhancing a very old BeOS application long lost in time. While browsing the Haiku kit and application source tree, sometimes I stumble upon some new (at least for me) but also interesting small elements that the Haiku operating system added to the Haiku API during its development. I like to try these elements out. Most of these API additions might change or even disappear in the nearest future, since I understand their development process is not yet finished, but they're interesting to know nevertheless.
Come visit my Haiku Blog-O-Sphere page and read my new blog-entry - Bits and Pieces: Notifications and Menu Builders.
The Flatconf project has been part of my interests since long - from the very first moment I started cooperating the ASN Labs team. Not a very well known project, from what I know it was only used in the old Lintrack distribution. It's more of an interesting experimental concept than an innovative solution. Flatconf is an attempt of creating an universal configuration system based on the idea of 'flat files' and the usage of the file-system as a natural database. Currently two versions of the specification exist, with the newer one (2.0 draft) using a new concept for holding variable meta-data - not entirely a good one though. But, just now, I thought about the original idea and came up with some thoughts for modifying it, making it little bit more feasible. Flatconf 1.5 anyone?
Most of you probably at least heard about the Haiku operating system. For those who didn't or just know the name, Haiku is the open source recreation and spiritual-successor of BeOS - an alternative multimedia-oriented operating system discontinued some time ago. Today's post will be a short collection of brief, random informations regarding its application programming interface (known as HaikuAPI). An API that I consider very consistent and intuitive to use.
Not sure if this is a common bug for everyone using a hand-built OpenWRT on Ubiquiti RouterStation Pro platforms, but at least I notice it on all the boards I have in my possession. When booting the OpenWRT kernel and watching the printk() output, rubbish data can be seen in the kernel command line parameters - in normal cases. Usually this does not break anything, but as we know, RedBoot in Ubiquiti boards passes board-specific parameters to the kernel command line with information such as board type, ethernet MAC address etc. Sometimes those parameters are not passed and parsed correctly because of this. I did a small investigation why this happens.
During programming in C for work yesterday, I popped into a small issue I did not expect. I was concerned because a piece of code that I normally thought would work (and it did, but in other circumstances) - this time did not. I wanted to better understand this problem and in the end learned a bit about the Stackguard in gcc. Some of you probably heard about it already. Consider the following piece of code below.
Quite recently, I was asked by a colleague to maybe include an RSS feed on my web page. I thought that it might not be a bad idea, considering that I am not doing updates too frequently. So I added an Atom Feed for the development part of my web page. Since I am not using any CMS system here - only some minor PHP scripting help - having a small amount of time, I decided writing a quick Python app converting my HTML content into an Atom web feed XML file.
In this post, I will try to write about how to use the basic UniConf API. This is an unofficial guide to UniConf, so be advised. I will concentrate on the native C++ version of the API. This can be thought of as something like a small UniConf tutorial.
While writing my thesis some time ago, I did a small review of existing configuration systems in use. One of them especially caught my eye - UniConf. The authors once called it the "One True Configuration System", which might sound a bit provocative, but has a seed of truth in it.
Another short post. I've seen some people having trouble with proper including of development tools in the Haiku image. The process is very simple, but indeed there is not really much information about it. All the development tools (like gcc, ld, autotools, perl and more) are packed in so called Haiku Optional Packages. You can browse the list of available optional software in the build/jam/OptionalPackages file in the Haiku source tree. Some of them can be installed by using the in-system application installoptionalpackages as well, but that's another story.
This is a trick that my colleague MichaÅ WrÃ³bel showed me when I had problems with slow git response on my local repository. Sometimes it strangely so happens that git status becomes really really slow, taking even a few minutes to complete - on a big, multi submodule repository in this case. This can be really annoying. Quoting my colleague:
More basics. The Linux kernel offers an interface for browsing and modifying system parameters, mostly kernel related. This interface is called sysctl. In Linux, sysctl variables are available to the user as normal, editable files through a virtual filesystem browsable in the /proc/sys directory - or by the usage of the sysctl application. In my today's post I would like to concentrate on how to create sysctl configurations in kernel code.
During work on some things regarding my master thesis, I stumbled upon something I did not know about before. I'm not much of a reverse engineer, and I don't really have the time to look into it closer.
Today a quick post about something obvious - file reading/writing in kernel space. First of all, I'm obliged to inform you that this practice is very bad and shouldn't be done for purposes other than e.g. temporary debugging. You can find out why it's bad and how to do it properly here.
Today will include a small advertisement-like post. Cross compilation has always been a bothersome process. Right now it's not as bad as it once was though - yet, still it can be time consuming, especially if you want to create you own GNU/Linux system for a different platform. For proper cross-compilation, we first need a specific toolchain present that will be able to generate code for our architecture of interest (we can use crosstool or OpenWrt here, for instance). Usually, this can be a troublesome as well, even more if the platform we're interested in is relatively unpopular - but we will skip this case for now and return to it in a later post.
It seems safely unloading a Linux kernel module in kernel space is not a very straightforward task, but once you see how it's done, it seems awfully trivial - and strange. Those of you that had some kernel programming experience before probably know about the request_module() and its non blocking version request_module_nowait() functions declared in include/linux/kmod.h. Just provide the name of the module you want to load as the parameter and the function takes care of the rest. Sadly, there is no such function for loaded module removal.
Some time ago, I have been given the opportunity to work on the Mikrotik RouterBoard 433AH platform. The RB433AH is mostly same as the RB433, just a bit more powerful. It has the standard Atheros AR7130 chipset clocked at 640 MHz (some weaker versions involve a 300MHz processor), 128MB or RAM, 3 10/100 ethernet ports, 3 MiniPCI slots and a microSD card reader. A more detailed hardware specification can be found on the RouterBoard page here. Pretty interesting piece of hardware. One thing that we need to get ready for is the serial port, since in this platform we need a null modem cable for connection.
With this first post, I would like to welcome everyone to my personal web log. I intend to post here about my experiences with technologies that I encounter at work and during private research. Since my interests include embedded systems, kernel hacking, GNU/Linux programming and the Haiku operating system, you can expect a bit of those in the near future. Since I am also an amateur artist, you can find some of my artworks in the Art section.