The Next Sources to Release

High on our list we have:

• The Shared C Library
• The Postscript printer drivers (? I can’t remember) for Martin Wuerthner
• Browse for Andrew H and others
• ScrEdit for Colin
• Draw and DrawFile modules
• The APCS.* header files which stop some released stuff from building

If you have something which you really want to see the sources to, add your request along with your reasons here and it will help us to set the priorities for what we work on.

Also, if you want to help us to release sources (with only three of us doing this in our spare time, it’s going to take a long time) then get in touch by sending an email to info@riscosopen.org. Note: if you can help, you will need to sign a non-disclosure agreement with us or Castle Technology as, of course, you will be accessing the ‘raw’ RISC OS sources before they have been processed for release.

Thanks! :-D

• The bit image printer drivers.

The reason is to make it possible to fix UTF-16 printing with these printer drivers, as used by NetSurf. Currently Font_Paint usually fails with “Illegal control character in font string” when printing.

We’re not sure where exactly the problem is. I assume it’s in PDriverDP or the PDumpers, but it might be in the Font Manager.

My vote is for the Shared C Library. A lot of useful software is provided nowadays not in the form of standalone applications but as embeddable libraries. It makes no sense for applications all to be reduplicating the same code. Candidates that I have in mind for making into shared libraries are things like zlib, pnglib, jpeglib, lualib.

Following on from the other thread we mustn’t forget RISC_OSLib, which lies underneath the various applications.

Having said that, it’s probably not worth listing individual libraries. A RISC OS ROM build includes a plethora of such things, from entirely proprietary internal code through to popular open source components like zlib. I expect that we’ll be releasing those bit by bit more or less as a background activity behind all the other source work.

Chris Hall said:

“Please release the source for the ARM BASIC Editor, called up from BASIC by ‘EDIT’, so that it can be 32-bitted. Yes, I do still find it helpful and always irritating when I get the message “File ‘ARMBE’ not found”.”

The sources to as much of the tool chain as you are allowed to release. Specifically, things like Squeeze. Possibly under a more liberal licence that would allow us to run them under UNIX for cross-compiling purposes.

I understand that that reasons the compiler etc cannot be released is because of agreements with ARM etc, even if it were only released in binary form for free. Is there any likely hood of this agreement being changed, given that it hardly competes with ARM’s products anymore (in code quality, thumb output, chunked stack nastyness, etc).

I’d like to see the Window Manager opened up, so that the relatively simple business (I’m guessing) of improving RISC OS’s look and feel can be addressed. I’ve written a short note for discussion on what those changes might be. I’m not competent to make the underlying modifications myself, but I’d be happy to do work on the sprites and theme management apparatus which would follow work on the core Wimp API.

Chris, your technical note appears to be futuristic. A year in the future, to be precise. Also: almost all your suggestions can be done without the source with a hack module: I’ve done most of them in the past.

Rob: Whoops, sorry. Either I’m a Timelord or my finger slipped on the keyboard…

Anyhow, I still think there’d be some value in making the changes I suggest to a future R05 release, especially as (as you imply) they’d be fairly easy. Although no expert, I assume that implementing them in the source is likely to be more stable and robust than a hack module, with the added benefit of wider distribution.

Can I add the toolbox modules to the list.

I would also very much like to see Window Manager sources released.

Another vote for the Toolbox.

My vote is for the Draw and DrawFile modules.

I think the Toolbox modules, Draw and DrawFile would be pretty straight forward. Also, DragAnObj and DragASprite would be reasonably easy, I think. I’m just refining the shortlist for the next things to go out now.

The only problems are some of the libraries which these things require to build. For various reasons, they are the things which are hard to release so they make it problematic to release the other code because without the libraries, it’s not much use.

Now that the Wimp sources are released, is anyone interested in working on the desktop look and feel? I’m not competent to have a go with the sources themselves (which seem to be in assembler), but I’d be interested in working with someone who is in order to refine the system and make it fully themeable. My note, linked from one of my earlier posts above, is still online, in case anyone wishes to make any comments. Drop me a line at cdwraight [at] yahoo [dot] co [dot] uk if you’d like to discuss.

Can I vote for the Unicode stuff as well as the International Keyboard Handler Generator for the next release? Last time I contacted Castle (a few years ago) they told me making keyboard drivers was something that required access to the source code so they couldn’t release IKHG. So at the moment it’s impossible to add other keyboard layouts.

A lot of the Unicode support, in the form of the Font Manager and International module, were in the batch 2 release. Granted, we haven’t got round to InternationalKeyboard and IKHG yet…

I think he probably means the Unicode resources as well (e.g. !Unicode). I don’t think that went out in Batch Two.

Can I make a couple of low priority requests for the next round:

The USB stuff and DeviceFS. I guess that consists of USBDriver, SCSISoftUSB (possibly OHCIDriver and EHCIDriver, though I don’t think I need those…) and DeviceFS.

DeviceFS has a one well known special field processing bug and I’d personally like to add support for string arguments in the special fields.

As for USB, the use of BULK endpoints is problematic at the moment in some useful situations (at least in the only two situations I’ve attempted to use them: PTP and Ethernet). I’d like to add to the API to avoid having to access the USBDriver workspace directly and to make a few things easier to do.

What else does everyone want to see in the next lot? Any more special requests or bits that we’ve missed? I think we’ve currently got:

• InternationalKeyboard
• IKHG
• !Unicode
• DeviceFS
• USB stack
• More of the !Boot sequence
• Draw and DrawFile modules (we missed these from Batch Two)
• TextGadgets module (also missed from Batch Two)

All requests, suitably scribed upon the reverse of a beer token, very welcome.

I’d also be interested in the NVidia and PCI modules.

I think we also need to get BASICTrans out, seeing as BASIC is already released.

How about the hourglass?

I’ve got a half-formed idea to change it to get the hourglass sprites from the wimp pool, rather than having them built into the module. This would make it easy to have a customised hourglass for desktop themes.

Before people get their hopes up about IKHG, I should point out that it was never updated to Unicode support. This would be a fairly major task, not least because you’d need Unicode system font support as a prerequisite. To get keybord support up and running in a reasonable development time, the InternationalKeyboard source was changed so the master keyboard layouts are stored in human-readable text. The benefits of a GUI in this scenario are so limited that IKHG was deemed obsolete, and it has in fact been deleted from the source tree.

I know this has been mentioned before, but I would like to see RISCOS_Lib being made available. So much of the functionality of Edit/SrcEdit seems to depend on how things are implemented in RISCOS_Lib, it’s difficult to see how things work at the lower levels without access to the sources.