ChoX11 and PortingBy Peter Naulls. Published: 14th Jun 2004, 23:15:32 | Permalink | Printable
Bring it to RISC OSEver seen some Linux application and thought: "the source is available, why can't we have that on RISC OS?" And indeed, because of the efforts that have been made on the GCC port for RISC OS and its C library, Unixlib, this is possible for a large number of Unix applications.
The issue is that most of these applications remain command line based, because access to GUIs is so different between RISC OS and pretty much everything else. One notable exception to this is applications using the RISC OS port of libSDL, or Simple DirectMedia Layer. This library provides a blank canvas for programs to draw into, and is consistent across Windows, Linux, MacOS and number of other OSes including RISC OS. This is great for games, where a blank canvas in a window (or full screen) is exactly what you want, and indeed a number of games have been ported to RISC OS which use this.
Not Just Games
That's all very well, but if you look at the list of programs using SDL most them are not serious applications, and the majority of interesting applications for Unix make use of the multitude of other libraries available. To the left you can see an example of an SDL game, BomberMan.
Direct to RISC OS
There is another approach which is applicable to a small (too small, really) number of graphical applications. That approach relies upon a split between the actual functionality of a program, and its interface to the system's GUI - this is also often an indicator of good program design. In practice, there are only a few applications I've come across that do this, because in most cases, that job is deferred to a GUI library. Examples of programs that do this include FreeCiv (although the RISC OS port of this in fact uses SDL), RDesktop, and a handful of others.
In these cases, it is relatively straight forward to do a RISC OS version given a bit of time. You also need to hope that the maintainer cares enough to accept your changes (only sometimes a problem), and that you keep up with minor API changes in new versions (usually only minor effort).
When a program does not have this split between GUI and functionality, then the problem is considerably harder. Splitting a program's functionality up in this way, or trying to directly graft in RISC OS code is an enormously complex task for even a moderately sized program. And even then, if the "upstream" version of a program changes, then you face a nightmare of maintenance unless you can resolve it with the program developers. Finally, after all that effort, you've still only resolved the problem for one program - there are hundreds more to be considered.
Libraries and X
The crux of the issue is libraries. Ultimately, all communication between a program and its GUI is via a library of some kind (RISC OS Wimp SWIs I'm counting here loosely as a library). Under Unix (and Linux), almost all graphical programs use a library that communicates with the X Window system such as GTK+, Qt, Xt, Motif (Lesstif), SDL and many more, including the lowest level library, Xlib. These libraries are often known as "toolkits", and are very similar to RISC OS libraries such as DeskLib and the RISC OS Toolbox.
Many of these libraries are easily (depending upon your interpretation) compilable for RISC OS - RiscXLib contains RISC OS versions of Xt and Xlib for example. So, what happens if you compile a program from Unix against these? Well, Xlib is socket based, and will try to connect to an X Server.
X Servers certainly exist for RISC OS, such as RiscX, and whilst RiscX is certainly useful in its own right, the result with RISC OS program is pretty disappointing. The program will need to run in a TaskWindow, and RiscX displays its own window into which all programs will display their output. You'll also need a window manager like twm to even move things around, and on to of all that, it's distinctly on the slow side. Not much fun.
The slowness is probably caused by a number of things, and the exact cause isn't entirely clear. There are obvious bottlenecks because all the graphics have to be sent over the TCP/IP stack, even for things running locally. Running everything in a window could be fixed too. For example, MacOS X makes good use of a "rootless" X Server, to allow X applications (which can run locally or remotely) to display alongside native MacOS X applications. RiscX could be potentially modified to do this, and to provide the needed window manager behaviour itself - the title bars, scrollbars, and moving all now being performed by the RISC OS Wimp. A rootless RISC OS X server, too, would be very useful in its own right, but unless performance issues can be solved - and it would never be as fast as "native" drawing - then that is still far from ideal.
Some years ago, I was given access to a version of GTK that had the sort of operation I described above performed to it - that is, RISC OS functionality had been grafted it. This had been performed by Angelo Melis. Although it was a noble effort - even at that point, GTK had moved on considerably from the original sources it was based upon, and the conversion was not complete, meaning it was not entirely useful, although it would run some simple examples.
True, GTK is something of a different beast these days - there is a version for Windows for example, and the OS specific functionality could be done for RISC OS (the original RISC OS conversion sources would not be any use for this). This is certainly a practical option, but the downside is that, even though GTK is a very popular choice for applications, it still excludes you from the rest of the applications that do not use it.
Of course, there is never a silver bullet, but I decided that replacing the Xlib library would be the most practical option, and given enough effort, yield far more numerous and useful results than any other option. What's important to note is that Xlib is the library at the very bottom of the layers of X libraries. GTK, Xt and all the rest must pass all their commands to the X Server via Xlib.
This means that all the graphics commands can be intercepted at a common point, and directed straight at the RISC OS Wimp instead of via a complex layer of TCP/IP and X Server. It also means that all the X libraries (and there are often quite a number of supporting libraries for even a simple X app) can remain completely unmodified, as can any toolkit libraries such as GTK. It also means we have slightly more control over low level behaviour.
The downside? Xlib has a massive number of functions; around 400 at last count. Most applications don't use more than a small number, but the selection varies, and it's still a lot of work. Xlib also has little concept of GUI concepts such as menus, title bars, scrollbars, etc - the implementation of these is handled by higher level toolkits (hence the large diversity of appearance you sometimes see in an X Windows desktop), or in some cases applications do these entirely themselves; and so many applications could potentially look very un-RISC OS like.
Making ChoX11 happen
ChoX11 has been a while coming, there's no doubt about that, and no surprise given the large number of functions involved, and sometimes poor documentation on Xlib. It certainly wouldn't be as far on as it is without the help of Chris Williams and Alan Buckley (who also originally ported SDL). Although ChoX11 is making some excellent progress, it's still not entirely complete, and could really do with contributions from other developers.
|To give an idea of its current status, we can look at some of the current things it can run. To the right, we have a screenshot of Tgif which is a powerful vector drawing application, similar to Draw in functionality. Tgif doesn't make use of any toolkit, but instead draws all its own widgets via the Xlib - and in this case, via ChoX11, therefore acting as a RISC OS application. Tgif almost works sensibly, but there are still some loose ends in ChoX11 to make this a usable application.|
|Next, we have a well known X application, XClock. This, and a great many older X applications make use of the Xt widget library. As you might expect, this communicates with Xlib (or ChoX11 in this case) and it is a functional, if not particularly useful, RISC OS application.|
|The next example is a GTK one, which only recently began to work sensibly with ChoX11, and displays a variety of GTK widgets, and gives an idea of things that do and do not work.|
I have many more examples like these, but the ones above give a feel for the status of development.
ChoX11 has its own page and the most recent version is accessible via CVS. A prebuilt version is also available, but this may be out of date, although it is updated occasionally. You should look at the CVS version if you wish to look at it seriously, since it is updated regularly.
ChoX11 does take a great deal of code from Xlib itself, but also has much original code. It interfaces to DeskLib to talk to the RISC OS Wimp, and you will need to link to this too. DeskLib is sometimes updated to fix bugs found whilst developing ChoX11 or add features required by it. DeskLib can also be fetched via CVS although this is less important, and the latest release may well be fine.
There are also some examples which can be downloaded from the Unix Porting Project - note that some of these have been reported to be somewhat unstable, as might be expected from code under development.
ChoX11 is of course an integral part of the Unix Porting Project, although any contributors will receive subscriptions.
You can see ChoX11 in action at the forthcoming RISC OS show.
Taking Things Further
Obviously, the most important thing is to complete the missing ChoX11 functionality, and therefore allow useful, real world applications to run under RISC OS. Beyond that, there is one issue I mentioned earlier - that applications will often not look like RISC OS applications apart from being in a RISC OS window. X applications will conform to the look and feel of their toolkit, or in some cases, a completely unique look of their own. In particular, you should expect drop down menus, and (yuck, I hear you cry) file saving and loading dialogues instead of drag and drop. You can bet that developers of these applications most likely won't have heard of the RISC OS style guide.
I suspect in practice that people will not be overly bothered by this, because of the huge advantage of being able to run the programs at all on RISC OS. Nevertheless, it's at this point that some limited modification of libraries like GTK might be advantageous, such as teaching it about RISC OS pop up menus. The precise implementation of this, and how effective it might be remains to be seen.
I think you can now see how useful ChoX11 might potentially be to RISC OS in allowing large numbers of previously unavailable software to run, even if they aren't style guide compliant. Of course, natively developed software will remain very important to RISC OS - ported software will rarely run as fast as a native version, nor is it likely to fit as well into the RISC OS desktop (unless considerable work has been done on it), and there's certainly no intention to displace it. The problem is that RISC OS has had for a long time, a very small number of developers, so it's important to do as much as possible with limited resources. ChoX11 (and also Unixlib and GCC) allows RISC OS to tap into a rich resource of software which is undergoing continual development, and has a huge variety. I hope you'll agree.
ChoX11 and RiscXLib
GCC for RISC OS
Xlib programming reference
ChoX11 is developed by Peter Naulls (a drobe editor) and Alan Buckley, with contributions by Chris Williams (a drobe editor) and others
Previous: STD suspends A75, A6 range
Next: VA halts VirtualRiscPC deliveries
DiscussionViewing threaded comments | View comments unthreaded, listed by date | Skip to the end
Please login before posting a comment. Use the form on the right to do so or create a free account.
Search the archives
Today's featured article
NetSurf bags GBP10K investment from Google
Four uni coders lined up to improve web browser
35 comments, latest by tlsa on 24/11/08 4:19PM. Published: 21 Apr 2008
Hide documents in spritefiles: David Thomson aims to beat all Steganography encrypting software
Discuss this. Published: 10 Nov 2000
News and media:
RISCOS Ltd •
RISC OS Open •
MW Software •
Advantage Six •
CJE Micros •
Liquid Silicon •
Chris Why's Acorn/RISC OS collection •
The Register •
The Inquirer •
Apple Insider •
BBC News •
Sky News •
Google News •