Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

ChoX11 and Porting

By Peter Naulls. Published: 14th Jun 2004, 23:15:32 | Permalink | Printable

Bring it to RISC OS

Ever 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
SDL GameThat'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.

Fixing things
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.

Fixing libraries
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.

Introducing ChoX11
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 logoChoX11 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.

TgifTo 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.

XClockNext, 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.

GTK WidgetsThe 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.

Further 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.

Winding Up
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
GTK Toolkit
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


Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

Ooh, this is very exciting, might even prompt me to start developing for RISC OS again.

Does this mean we can use such toolkits as wxWidgets (basically a GTK wrapper) or do we have to directly call GTK (or X11/Motif)?

Anyone know the status of Python on RISC OS, I noticed "riscos" is one of the os.name strings....?

 is a RISC OS Usersimo on 15/6/04 12:11AM
[ Reply | Permalink | Report ]

simo: I used Python on RISC OS a month or so ago, it was in a very good state, it could run all my scripts with no modification, and it's WIMP support is very good indeed.

 is a RISC OS Usermugent on 15/6/04 12:36AM
[ Reply | Permalink | Report ]

A very interesting article indeed, hopefully there will be some worthwhile gains for all from this excellent project! Unfortunately I don't feel excited enough about it to want to help :/ I'm busy with some other project right now as well. However, keep up all the good work :)

 is a RISC OS Userjohn on 15/6/04 1:05AM
[ Reply | Permalink | Report ]

This *is* hugely exciting! An excellent article, offering a clear explanation of the concepts and strategies involved. Thanks, Peter!

PS Without wishing to seem overly pedantic, I wonder whether Drobe articles could be 'spellchecked'. It would only have taken a minute to catch *most* of the infelicities above. There is, of course, a good range of such apps under RISC OS, so there's no need to port a spelling checker ;-)

 is a RISC OS UserStewy on 15/6/04 1:11AM
[ Reply | Permalink | Report ]

In simple English, does this article about ChoX11 means that non compatible RISC OS software (and any files) from another platform, now may run on RISC OS? So with ChoX11 can I import/export files from programmes of the same name on RISC OS and/or Windows? Also, does RISC OS mentioned here mean 26 or 32 bit, or both? "RISC OS for Dummys" is closer to my level of understanding the jargon. :angel: Cheers, Steve.

 is a RISC OS UserSawadee on 15/6/04 2:36AM
[ Reply | Permalink | Report ]

"RISC OS for Dummys" answer: NO to all of that.

ChoX11 just means that graphical programs can now be ported a little easier from Linux, it's not some sort of magical emulator.

I expect Chocky is writing this 26/32-Bit neutral

 is a RISC OS Usersimo on 15/6/04 3:26AM
[ Reply | Permalink | Report ]

simo: I don't understand the significanceof "directly call GTK". There's no magic here, programs are compiled and linked exactly the same way (within reason) as they they are on other platforms.

Saw: Yes, it does mean that. I'm not sure why you're bothered to ask if it's 32-bit - of course it is; making new applications/libraries 26-bit only these days is hugely pointless; not to mention that the source is freely available.

 is a RISC OS Usermrchocky on 15/6/04 7:47AM
[ Reply | Permalink | Report ]

'In reply to mrchocky:' While I am trying to (and starting to ) get the idea of how to use correct 'figure of speech' (terminology) used by the many Drobe users, does the word/term RISC OS means 26 and 32 bit? I think where I have been confused is that when RISC OS is mentioned, to me it is not referring to the Iyonixs (32 bit). Sorry if the question sounds frustratingly dumb my previous comment. Yes, I have thought that it would be the obvious thing to do, make any new software 26/32 bit. It was just previous articles on Drobe about Select and possibly any other RISC OS Ltd stuff that may still only be 26 bit, that is what lead me to ask. Even so, I agree with the thought that it sounds great that it means just graphical programmes can be ported easier. I would assume this means not only games, but graphic educational software for schools?.... :grin: Wow! What else is graphical......? Cheers, Steve.

 is a RISC OS UserSawadee on 15/6/04 10:42AM
[ Reply | Permalink | Report ]

I'd like to point out that as far as technical terms go I'm at the "RISC OS for Dummys" level too.

Assuming that ChoX11 is completed does this mean that linux desktop applications could run under RISC OS unmodified?

If so with decent hardware (ie. Iyonix) would larger desktop applications such as openoffice run at usable speeds?

 is a RISC OS UserHerm on 15/6/04 10:52AM
[ Reply | Permalink | Report ]

Again, I think you could say a lot more with a lot less in your comments. There's no need to assume not just games - the article discusses this in quite some detail.

[link] explains 26-bit vs 32-bit. In short, almost all new software will run on all systems.

 is a RISC OS Usermrchocky on 15/6/04 10:56AM
[ Reply | Permalink | Report ]

Without meaning to be a miserable git, this project has little appeal to me, personally. > 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 The only reason I use RISC OS is because of the "look and feel".

What other reason is there?

> I suspect in practice that people will not be overly bothered by this [non-RO GUI] Hmm, if I want to use a Linux/Windows program then I do so on a PC! I guess the project will be useful for those who do not have access to an x86 PC though :)


 is a RISC OS Useradamr on 15/6/04 1:20PM
[ Reply | Permalink | Report ]

Sounds like exactly what I've been after. So when will we be able to start using it to write native apps for Risc os? ie. Use the GTK toolkit on Risc OS. If this doesn't kick start the programming on Risc OS I don't know what will.

It goes without saying that I am mightly impressed by the work done so far and the determination to make it suceed. I'll be doing a bit of downloading tonight when I get back home from work to see what the current version of ChoX11 can do.

I am terribly excited by this.


 is a RISC OS Usernytrex on 15/6/04 1:21PM
[ Reply | Permalink | Report ]

Blimey, it's mightily hard to construct well-layed-out post here :(

 is a RISC OS Useradamr on 15/6/04 1:22PM
[ Reply | Permalink | Report ]

adam: Looks to me like you haven't read all of the article wrt L&F issues, and are making some unfounded assumptions.

Even then, as you say, the reason you use RO is the L&F. But at the same time, the reason you _don't_ use it is lack of functionality in given areas - that's what this project addresses, and allows you to use new apps, even if they aren't entirely RO ones, in an environment which is still RO.

Please also read the bit about making libraries have some RISC OS functionality. If we sit on our arse and insist we're not allowed apps that aren't entirely style guide compliant, then we will assuredly go nowhere fast.

ny: you'll be do that at precisely the same time as you can use ported applications - i.e., when remaining issues are fixed - hopefully with the help of people like you.

 is a RISC OS Usermrchocky on 15/6/04 1:36PM
[ Reply | Permalink | Report ]

I've got my UPP subscription. Have you?


 is a RISC OS Userfylfot on 15/6/04 2:02PM
[ Reply | Permalink | Report ]

Good news indeed about using GTK toolkit. I created a sopisticated Library in BASIC that would allow me to easily create complex GUI's very easily in a similar way as it is done using GTK and VB. ie By setting a few variables I could change how window backgrounds are tiled (centred, scaled, horizontally, vertically or both), where windows are displayed on screen (or in parent window), and lots of other properties. Never quite got round to implementing the rest of the code to do the same for icons and menu's though. Shame, really because it really was quite good! The intention was to make it easy to write apps for RO without worrying about the GUI.

Looking forward to the release.

I now have a reason to start using C on Risc os.


 is a RISC OS Usernytrex on 15/6/04 4:35PM
[ Reply | Permalink | Report ]

Excellent article, well explained.

 is a RISC OS Userchod on 15/6/04 11:45PM
[ Reply | Permalink | Report ]

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

  • ChoX11 and Porting
    Bring it to RISC OS
     17 comments, latest by chod on 15/6/04 11:45PM. Published: 14 Jun 2004

  • Random article

  • Expo 2004 show photos
    See for yourself
     4 comments, latest by MENTAT on 30/6/04 2:58PM. Published: 24 Jun 2004

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign

    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "RISC OS development is a waste of time with [Drobe's] aggressive attitude towards reporting and disregard of facts"
    Page generated in 0.1379 seconds.