5.18 stable release wishlist

Sprow mentioned to me over the weekend that he’s “volunteered” himself for the job of preparing a 5.18 stable release, which will then be sent through Castle for testing. The aim is to get it out sometime in the next couple of months, but we’ve got a brief period now where we can do any small bugfix/polish tasks that will help make the release more well-rounded.

Here’s the list of things that I’m hoping to get done by the deadline (whenever that may be – I’m not sure if there’s an official one yet):

• Sort out what’s happening with SharedSound – i.e. whether it should be placed in ROM images or on disc. In my opinion programmers should be encouraged to use the module, so we should make it as easy to use as possible – i.e. include it in the ROM image, like Select does. Does anyone here have any alternate viewpoints?
• Add NetTime to the disc image
• Merge in TBA’s VFP/NEON BASIC assembler
• Add the new OS_Heap reason code for allocating aligned blocks of memory, and fix the PCI module to make use of it (the code for most of this already exists, I just need to rip it out of the HAL USB libraries and put it back into the kernel)
• Fix HAL_UARTModemControl
• Sort out as many issues as possible with CDFSSoftSCSI/USB CD drives
• Try squeezing the SCSI modules into the Iyonix ROM image (unless anyone has any objections?)

Is there anything else people can think of that would be quick to do and benefit most/all of the supported platforms? At this point I’d usually want to start hitting any bugs in the bug tracker, but it looks like it’s still down.

Sorting out the ROM branding in time for the release would be nice, but I suspect that’ll be mostly out of my control. I’m not even sure if R-Comp have been approached to perform QA for a stable ARMini/OMAP3 release.

SharedSound – i.e. whether it should be placed in ROM images

if it fits, it ought to be. (in an emulator, SharedSound could presumably be replaced by a wrapper that talks directly to the host sound system.)

Add NetTime to the disc image

Isn’t this a different job? (i.e. not in the ROM)

Try squeezing the SCSI modules into the Iyonix ROM image

Yes, please.

Sorting out the ROM branding in time for the release would be nice,

Would modernizing the window furniture be an option?

‘Modernizing’ window furniture is the sort of thing that will get people up in arms about the “horrid” new icons :)

I suggest such things should be provided as an optional extra – isn’t there some sort of theme manager already available?

If so, could some of the Modern design proposals be included?

Add NetTime to the disc image

Isn’t this a different job? (i.e. not in the ROM)

Kind of. I was thinking about it from the point of view of that there would be an official/tested disc image to go alongside the official ROM release. But I think the ROOL disc image is still classed as a work in progress, so there haven’t been any official releases of it made yet.

Anyway, adding NetTime to the disc image is something that’s been on my todo list for a while, so now is as good a time as any to get it done. Remember that this is also something that will benefit the Raspberry Pi.

Sorting out the ROM branding in time for the release would be nice,

Would modernizing the window furniture be an option?

If you can find a design which everyone is happy with!

‘Modernizing’ window furniture is the sort of thing that will get people up in arms about the “horrid” new icons :)

Which was why I only asked for the furniture to be updated. :)

If you can find a design which everyone is happy with!

Is there any way we could have a poll? – (Iconbar have the facilities)

isn’t there some sort of theme manager already available?

Yes, so it would be easy to put the ugly ones back for anyone who so desires.

If you can find a design which everyone is happy with!

I’d like to propose:

They are a slightly modified set based on one of Chris Wraight’s themes, so obviously we’d need his permission!

• No tawdry textures.
• Looks like a more contemporary take on the style originally created by Acorn’s NewLook, that everyone’s used to.
• The icons have the same proportions that everyone is used to (e.g. no narrow scrollbar).

IIRC, the only change I made to the toolsprites was to change the “Active” window title bar colour from blue to the more familiar cream. I might have also changed the background texture to a flat grey. Also, it looks best without the dated looking 3D window borders option or the textured menu option.

That’s not bad, even to a luddite like me :) I like the lack of background textures. Unsure about the different icons for ‘iconise’, ‘resize’ and ‘toggle size’, but that’s just resistance to change :)

That looks great.

Like the overall look but suggest that the “cream” needs to be a little toned down and the icons need a little bit of work i.e the arrows are a little small but overall looks fairly clean and a little more up to date without going to far.

If we wanted a complete break then I do like the look of Rogier Hartgring’s second set of mockups though I would change it’s window furniture for something like the one proposed above.

They are a slightly modified set based on one of Chris Wraight’s themes, so obviously we’d need his permission!

Absolutely – more than happy :)

I’ve not really done any work on the themes stuff for a while, mostly as I got the impression there wasn’t much interest in it. However, I have a nearly-finished theme manager plug-in that I’d be happy to make available if people were interested. It enables users to switch between icon sets/window tools from a single place, negating the need for Obey scripts in the boot sequence. If this were ever incorporated into the OS, it would allow a default set of graphics to be included in ROM, with any number of replacement sets in Boot.Resources.Themes.

Here are some more sample themes:

Steel – the theme Michael based his on

Clarity – a very simple, clear layout

Acorn – for nostalgia

I also think that the arrows are too small in Michael’s proposal above, and in the Steel theme from which it is derived. But otherwise Steel and Clarity are good; it’s a pity that Clarity doesn’t make it clear where the divisions are between the buttons on the title bar, which makes me prefer Steel. (I’d take the arrows from Clarity and put them into Steel.)

I still prefer pale yellow for a selected title bar.

A theme manager would be a welcome addition to the disc image.

There have been some references recently to whether new things would fit in the ROM image. But is there any good reason why the BeagleBoard etc. ROM images shouldn’t be increased in size? There isn’t any limitation imposed by a physical ROM.

However, I have a nearly-finished theme manager plug-in that I’d be happy to make available if people were interested

How close to finished is nearly-finished? One of the arguments against changing the theme is that there currently isn’t a way for people who like the old theme to switch back. We’ve probably only got a couple of weeks available to decide on a theme to put in the ROM image, but should have several weeks longer to sort out the disc image because it won’t be going through testing. So if the theme manager can be put into the disc image by the time the official ROM is released then I don’t think there’s much stopping us from switching the default theme in the ROM.

There have been some references recently to whether new things would fit in the ROM image. But is there any good reason why the BeagleBoard etc. ROM images shouldn’t be increased in size? There isn’t any limitation imposed by a physical ROM.

Yes, there’s no reason why we can’t just increase the size of the OMAP ROM. But that won’t help us solve the fact that the Iyonix ROM is the one that’s almost out of space ;)

There should be enough space to add the modules we want for 5.18, but after that we’ll probably need to work on compressed ROM image support so that we don’t have to worry about running out of space again (hopefully!)

I also think that the arrows are too small in Michael’s proposal above, and in the Steel theme from which it is derived.

I seem to remember thinking the same when I first started using them, but I’ve come to like the understated look. Also, unlike the other furniture buttons, the scrollbar bump-buttons can’t really be anything else given where they are positioned at scrollbar ends. :)

How about zip/unzip from the CLI? Or does the licence mean it’d be reserved for the disc image for putting in Library?

I’m not sure whether the zip/unzip licence would allow the utilities to be placed in the ROM image. But regardless of that, there certainly won’t be enough space for them in the Iyonix ROM image (and there probably won’t be enough time to sort out compressed images).

Is it a massive task to switch the Iyonix to compressed ROM images?

My understanding is that there’s always the potential to cock up the build process and then have to spend time reverting to the non-compressed one. Not exactly what’s needed when a reliable system needs to remain in place for the R-Pi build.

Steel looks great to me.

Basically though, the requirement is something that doesn’t look contemporary with GEM or Windows 3.

(And when is that new theme manager available? It sounds like a big improvement.)

—

If all the modules can’t be fitted in the Iyo ROM yet, can the missing modules be supplied with the ROM to be merged?

Can softloaded Iyonix ROMs be bigger than the physical ones?

Is it a massive task to switch the Iyonix to compressed ROM images?

It’s not exactly massive (i.e. I wouldn’t say it’s big enough to warrant being a bounty task), but it’s not a small task either. Several different parts of the sources and build system would need to be modified, which would easily take several days, maybe a week or two to get it fully integrated and tested.

If all the modules can’t be fitted in the Iyo ROM yet, can the missing modules be supplied with the ROM to be merged?

Yes, that could work. It’ll be easy enough to modify the build system to include a !System or !Boot update that can be merged in with peoples existing boot sequences.

Can softloaded Iyonix ROMs be bigger than the physical ones?

Yes (although I think the softload tool might need modifying to cope with it)

Chris Wraight wrote ;
I’ve not really done any work on the themes stuff for a while, mostly as I got the impression there wasn’t much interest in it.

Hi Chris,
I’ve been using Steel for over a year now and love it.
My !Flicker and !Iconizer software each include a ‘steel theme’ option so that they look perfect with your design.
While I like the Iyonix theme, it’s a very dated look – and whenever taking screen shots for RISCOScode or piLEARN
I always use the steel theme.
So a lot of interest in steel from me !
Regards,
Martin.

http://www.MathMagical.co.uk

Iyonix ROM size.
Could I request that the Iyonix ROM has all the drivers and features of the OMAP?

(Assuming a compressed 5.18 is unrealistic):

For 5.18 the bits that won’t fit coming with an archive of extras to merge.
For 5.19x the softload being bigger than physical ROM
For 5.20 the ROM being compressed

Add the new OS_Heap reason code for allocating aligned blocks of memory, and fix the PCI module to make use of it (the code for most of this already exists, I just need to rip it out of the HAL USB libraries and put it back into the kernel)

This is turning out to be trickier than expected. When I first wrote the code I didn’t spot that the heap manager forces all allocated & free blocks to be multiples of 8 bytes in length. This doesn’t work with the aligned allocator, since creating an aligned block will often require creating a free block which isn’t a multiple of 8 bytes, which then runs the risk of the heap becoming corrupt depending on what happens to that free block next. I’ve had a go at modifying the heap code to remove the 8 byte limitation, but now something’s broken and RISC OS won’t boot. So I’ve put these changes on hold until I have time to write a testbed that I can use to track down all the bugs.

Could I request that the Iyonix ROM has all the drivers and features of the OMAP?

In a minute I’ll have a go at compiling an Iyonix ROM with the extra modules added, so we can see if everything will fit.