Qtopia on the Zaurus
Most Zaurii come with Qtopia built-in. For detailed technical information about Qtopia, the best place to go is http://www.trolltech.com, http://doc.trolltech.com, or http://www.trolltech.com/developer/faqs. The examples I give here are based on my experiences with Qtopia 1.5.0, and with Sharp’s ROM 2.38 and Opera 5.0 and 7.30, and may differ from what happens on your particular setup, but the basic concepts should still apply.
My purpose here is to give a layman’s understanding of what Qtopia is and does, to help you understand, a little better, about how your Zaurus works. It took me a lot of muddling around to finally gain a somewhat decent understanding of this, and there still is a lot I don’t understand or haven’t learned.
The Zaurus is built on a Linux kernel, and what that means is that the bare bones skeleton of the Zaurus is a bunch of binary executable files, configuration files, and scripts. Where Qtopia comes in is as a middle-man, turning all that kernel stuff into a theoretically user-friendly set of GUIs (graphical user interfaces), which enable the user to run applications and modify the configuration files, without ever having to learn anything technical.
Well, at least that’s the theory. If there weren’t any bugs in the system, all the software was well-integrated, and appropriate hardware and software was easily available, it’d be a piece of cake. However, we don’t get that piece of cake.
The system came with many shortcomings. Members of the Zaurus community decided to write their own ROMs, mostly Qtopia-based, and Sharp kept coming out with upgraded software and hardware that wasn’t necessarily backwards or forwards compatible. And life with a Zaurus got even more befuddling.
What’s a ROM? It’s your distribution, the version of Read Only Memory that your complete operating system consists of, at least that’s my understanding without doing a thorough search of it’s definition. Some of the basic ROM and kernel stuff exists in “user space”, which means that the user is able to modify them. This is what makes it possible to upgrade applications and change configuration file information.
As I understand it, we then have at least three to five levels of software involved.
1. The Linux Kernel
2. Sharp’s modifications to the Linux Kernel
3. Basic Qtopia
4. The ROM built on the combination of Qtopia and the kernel, with some basic applications included
5. Additional software (applications)
Does that confuse you even more? If that’s too much too keep track of, I’m suggesting you think of the kernel, along with Sharp’s modifications of it, as the basic foundation. Then think of Qtopia as the structure built on that foundation, that gives you the ease and comfort of the GUI interfaces.
Some of the tools and applications you use were written by Qtopia (Trolltech), some were written by third-party companies, like TheKompany, Opera, and Netfront, and some by other users like you and me.
But if your ROM is based on Qtopia, all these tools and applications communicate with Qtopia and the kernel through the use of Qtopia’s qcop message system. And I believe it is problems with the way these messages are written, sent, and handled that causes many of the problems we often have with applications and hardware.
Many of us have had aggravating connectivity problems at one point or another, and I believe that most of these problems are due to the way the qcop messaging system works, which just doesn’t make sense with some setups.
If an application needs network access, or no longer needs network access, it generally sends a qcop message to network processes listening on the network channel. This would work fine if the Zaurus only had one network device and no more than one application ever needed to access that device, but hey, get real!
The Zaurus was set up to enable two simultaneous network interfaces, and many applications may request access to those devices. And that’s where the messaging system breaks down, at least for sure on the early ROMs, and I see signs of similar issues in the posts by people having other ROMs as well.
The problems I outlined in the next two pages here at Me and My Zaurus,
all were due to the way qcop Network messages get handled, and the solution for me ultimately resided in writing scripts combining basic kernel and qcop message commands.
How do qcop messages work? I use them a lot now. And I still only partially understand them, but let me try to explain just a little more about the qcop message concept, to give you the idea. Some qcop messages are kind of like general announcements, like “everybody shut down” or “is anyone here?” Others are very specific, and get sent only to a specific application, but even those have their problems.
The message system has been set up so that it “holds” a message, and delivers it the next time an appropriate application starts up. Unfortunately, this sometimes means that a message meant for a prior process or run of an application, still gets delivered even if it is no longer appropriate.
So, when an
Opera 7.30 session is completed, it sends a qcop message to Network devices, telling them, in a sense, “goodbye”. This message, unfortunately, gets added to the message stack, and can result in a network device shutting down for no apparent reason, one or two connection attempts later. This did not happen with the version
Opera, but it was too limiting for me, so I stayed with my upgrade to
Opera is not the only application that causes problems with the Network GUI and status. I also found that until I tweaked some basic kernel files, NEiC also caused problems, so I believe there must be other applications, as well, that may cause Networking problems through the Qtopia interface. If you want to see what I did to resolve these issues on my Sharp ROM using dialup, check out this page.
As another example, if we do something that makes qcop send two messages to qtmail to raise itself, it might mean a second copy of qtmail gets started, and they won’t know about each other! Qtopia 1.5.0 just isn’t smart enough to notice it’s sending a duplicate message, and very few applications are smart enough to notice the duplication either, to maintain just one active version of themselves running.
If you don’t believe me, just enter “ps ax” on the command line, or open your process manager, the next time you find an application getting whacky and raising itself several times, and see how many processes with the same name are running!
If you want to do much experimenting with using qcop messages to communicate with Qtopia, I recommend installing qcoptest, which is a debugging and testing tool. I also recommend installing qcop2 if you have a ROM (such as 2.38) that doesn’t have the ability to send qcop messages from the command line. It definitely is quite possible to use simple qcop commands with positive results.