First release of Skinny

I have released the first version of Skinny, a theme creator that I started some time ago.

This is an early release and most likely has some issues. It has been tested on RISC OS 6 and quite briefly on RISC OS 5 on the Raspberry Pi.

I am hoping to update it to take into account any future theme manager improvements should they become available.

At this time it requires the ROL Toolbox modules but these appear to work OK with the limited testing I have done.

I have released the first version of Skinny,

Interesting – but why build in a specific requirement for closed source modules when as far as I can tell on a quick test the application runs with the ROM based equivalents?
OLESupport 32 bit version is, I think, only available with a commercial application.

You don’t need any modules to do OLE.

You don’t need any modules to do OLE.

The application quoted has OLESupport as a required module in the !Run file.
Commenting it out doesn’t seem to produce any cataclysmic failure, in common with commenting out all the other toolbox module RMEnsures.

That was rather the point – that the !Run file sets up a requirement for specific revisions that may not be an actual requirement for the functionality and I wasn’t clear as to why this had been done.

I will try and address the above points. Excuse the typing, this is via my phone.

ROL modules – I haven’t done much testing yet on the RO5 modules and wanted to release something I was at least slightly confident would work. If testing proves this to be the case with the inbuilt modules I will use those.

OLESupport is available from the Sourcery page. I should have linked to it on the Skinny page. I was kindly allowed to link to the 32 bit version. It is used when
clicking the button to edit a sprite. I am open to other methods.

As I said originally, this is an early release!

ROL modules – I haven’t done much testing yet on the RO5 modules and wanted to release something I was at least slightly confident would work. If testing proves this to be the case with the inbuilt modules I will use those.

I think I may have sounded a touch snotty, my apologies.

OLESupport is available from the Sourcery page.I should have linked to it on the Skinny page.

Remember the saying: The only person who doesn’t make mistakes is the person that does nothing.

I had a suspicion the OLE element was a link to another regularly installed app. The problem was of course that the main users were going to be RO 5.xx users and the 32 bit safe status became important as a result.

Time to download the OLESupport module and test on ROOL modules rather than ROL. See what I can break. :-)

ROL modules – I haven’t done much testing yet on the RO5 modules and wanted to release something I was at least slightly confident would work. If testing proves this to be the case with the inbuilt modules I will use those.

Just to throw in my tuppence; I have two and a half RISC OS systems.

1. A RiscPC700. Doesn’t get used so much these days due to its age. When I uncover the piles of crap on top of it, I will check how the battery is doing. This machine runs RISC OS 3.70.
2. A Beagle xM. I would use it more if I wasn’t stuck with s-video hookup, but as a test-bed system for new software it is great as I don’t see an ARMv6 or ARMv7 emulator on the horizon. Plus, you can’t really beat actual hardware. ;-) Runs RISC OS 5.19 (a version about a month or two old, not gotten around to updating what I know works).

The “and a half” is an emulator for RISC OS 3.70 and another for RISC OS 5.19.

I have Toolbox modules. As far as I am aware, not a single one of them is the ROL version. I know I can install them, but I don’t see the point of installing something that isn’t being actively developed and is divergent from the version of RISC OS that is being actively developed.

Perhaps you need to step back and ask yourself “do I need this version of X in order for my program to work?”. If not, how old a version would work? Because the more specific you are, the fewer people will be able to appreciate your efforts.

I had this with some astronomical program (back circa Y2K). Written in BASIC, the first thing the software did was check for a StrongARM and bail out if not found. This wasn’t because the author used UMULL or some SA-specific instruction, but purely because he felt that it would have been too slow under older processors. I ripped that check out and… yes, the program was kind of slow, but this was to have been expected (and besides my other program running on a 66MHz 486/DX2 was about twice as slow). In essence, rather than saying “you really need a fast processor to get the best out of this”, the author arbitrarily decided that it was to be StrongARM only, thus restricting the range of people who could enjoy his work.

Rick, you are quite right of course and I have done just this with my other applications. The main reason was the scrolllist gadget which is fairly heavily used and which I believed may be an issue. As I say, once I am happy it works OK with the native versions I will make the appropriate change. I was eager to make some sort of release as I knew I wouldn’t be able to do anything for a few days after Monday so may have been guilty of releasing something sooner than I otherwise would have.

Steve, don’t worry. Glad for feedback and peoples views!

The main reason was the scrolllist gadget which is fairly heavily used and which I believed may be an issue.

Perhaps this could be an opportunity to identify specific modules that need update to provide such facilities.

I think it was Theo¹ who suggested elsewhere that updating specific modules and simply forcing others to a higher revision number could remove the requirement to go looking for external versions.

¹ Whatever the source of suggestion the idea is sensible – eliminate the requirement for closed source elements where even remotely possible. Where authors have used the features they are possibly best placed to comment on the usefulness vs. cosmetic.

For OLEsupport, the usual process is simply to contact me, let me know what you want to use it for, and I’ll grant approval with a credit in a textfile somewhere or whatever.

Although OLEsupport was originally by CC, their licence restrictions forced us to “clean room” it for Mpro in 1999. Subsequently, we have updated and developed it – current version is 0.30. I’m open with source code for bug fixing if required, although technically, it is private source being part of Mpro. It was last updated in April this year, I believe, with the assistance of (momentarily forgets name), erm, the chap who maintains Impact etc. Matthew Philips.

I’d prefer apps that need OLEsupport to include it with them – avoids too much confusion for users.

Andrew, I’ll email you about this as soon as I can. There seems to have been some confusion.

Following the feedback and comments made here I have released a new version of Skinny:

- removes the reliance on ROL Toolbox modules
- completely replaced the ScrollList gadget with something that better meets the needs of the application
- supplied OLESupport from R-Comp (thanks Andrew)
- some other bug fixes and cosmetic tweaks