|
|
|
| Beta! | About us | Contact | RSS | Webspace | Tech docs | Downloads | BBC Micro | Gallery | Wallpaper |
|
ChoX11 and Porting By Peter Naulls. Published: 14th Jun 2004, 23:15:32.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  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. 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 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.
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. Links SDL ChoX11 and RiscXLib RiscX DeskLib GCC for RISC OS 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 Discussion Viewing 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. |
Login
Create a new account Forgot your password? Search this website
This week's poll
Featured articles  Prototype affordable Braille display in developmentA low-cost computer-controlled Braille board has been prototyped by a RISC OS-using university student. Undergraduate Edward Rogers hopes to sell his completed units for as little as 200 quid each to schools and families to allow more blind children to continue learning Braille. And he said he wanted to launch his venture using RISC OS-powered kit before offering a package for other platforms.  9 comments, latest by flibble on 28/11/08 10:16AM. Published: 22 Nov 2008 Adventures with a Lego-cased A7K web serverHaving previously built desktop and laptop cases of out Lego bricks, model building Peter Howkins has turned his attentions towards crafting a slim box to slid his A7000 into a rack, alongside other rackmount servers. Having pieced together the housing, Peter puts a legacy RISC OS machine through its paces as an internet-facing server. 11 comments, latest by jess on 3/12/08 2:07PM. Published: 21 Nov 2008Would you swap your dusty Acorn for a polished Apple computer? Martin Hansen has been checking out the world of Steve Jobs and his range of shiny kit. 15 comments, latest by adh1003 on 6/1/09 1:06PM. Published: 17 Nov 2008Useful links News and media:Iconbar • MyRISCOS • ArcSite • RISCOScode • ANS • C.S.A.Announce • Archive • Qercus • RiscWorld • GAG-News Top developers: RISCOS Ltd • RISC OS Open • MW Software • R-Comp • Advantage Six • VirtualAcorn Dealers: CJE Micros • APDL • Castle • a4 • X-Ample • Liquid Silicon • Webmonster Usergroups: WROCC • RONE • NKACC • IRUG • SASAUG • ROUGOL • RONWUG • MUG • RISCOS.be Useful: RISCOS.org • RISCOS.info • Filebase • NetSurf Non-RISC OS: The Register • The Inquirer • Apple Insider • BBC News • Sky News • Google News • xkcd • diodesign |
Recently logged in: 
caveman • jmb • hubersn • jlavallin • Becky • lym • riscosboss • 
microbits • bengershon • Hairy • Stats
© 1999-2009 The Drobe Team. Some rights reserved, click here for more information | Powered by MiniDrobeCMS, based on J4U
"Drobe often has glaring factual errors that could simply be avoided with the bare minimum of research"
Page generated in 0.2126 seconds.
simo
