Toolbox: Scrolling list breaks action button?

Just to clarify a misconception in that bounty:

An alternative approach is to study the published documented changes and to use these to ‘clean room’ reimplement the missing features.

This is complete tosh. There is no requirement under European Law for “clean room” nonsense. The European Court of Justice rulings are very clear: If you have the legal right to use a piece of software, you have the legal right to reverse engineer that software for the purposes of interoperability, compatibility, or even just documentation of operation or interfaces. Ideas are not protected by copyright, and interfaces, apis and feature sets are ideas. It is only the code that is protected – you can’t reuse it without permission.

The pertinent ruling by the ECJ is C-406/10. Permission can be sought for access to original sources, fine. But alternatively and additionally code inspection can be carried out for compatibility. No precautions need to be taken other than not copying the actual code.

Just to clarify a misconception in that bounty:

I think the “clean room” wording in the bounty just means “reimplement what was already coded because we don’t have the original sources”. It does not include clean-room techniques for reverse engineering like you’d do for e.g. reimplementation of GPLed code.

In IT, we have so many phrases with not really well-defined meaning. I think the original form of “clean room development” was writing the code on paper, and if it didn’t work (e.g. because of a typo), it would be thrown away and implemented again from scratch.

Anyway, I think it would be more interesting to have a high-level overview of those magical things the RISC OS SIX toolbox stuff apparently includes. I don’t remember anything specific – I think there was a Gadget to make use of the IFR, but this is obviously a non-starter for Toolbox because it cannot be softloaded on old OSes. Or is that no longer a goal?

No, that’s not the etymology at all.

The phrase is taken from biological laboratory or manufacturing, meaning a process by which “contaminants” are prevented from entering – only the bits that are allowed through can get through.

Before the EU laws, reverse engineering required two teams (or engineers) – one to reverse engineer and document, and one to implement. The inspected code was seen as the contaminant, and the documented description the only thing allowed through.

As it could be proved that the team that wrote the code had no sight of the original code, it could not be an infringement. That practice is no longer required under European Law, although it is a sensible precaution when working in the US.

I think there was a Gadget to make use of the IFR,

ImageFileGadget

but this is obviously a non-starter for Toolbox because it cannot be softloaded on old OSes.

“It”? Toolbox? IFR? ImageFileRender will have to be reimplemented anyway.

https://en.wikipedia.org/wiki/Cleanroom_software_engineering

As I said, typical IT phrase overloading.

although it is a sensible precaution when working in the US.

… Until you meet a judge who decides that the API itself is a protected entity… https://www.theregister.co.uk/2019/02/26/google_java_supreme_court/

This is why I have a big thing against the GPL. It has some weird stuff in it to implement its viral nature, the stuff might make sense when seen from the point of view of a Linux kernel, but when applied to anything else (and maybe within Linux too), it is actually staggeringly ill defined and the GNU notes and explanations make several references to “the courts will decide”, and anybody outside of the land of Springsteen will know that the courts there are batshit crazy.

A licence is supposed to define what is and isn’t, with varying degrees of Draconian (software you paid for) or Permissive (software you didn’t pay for). Any that needs to insert language to the effect of “the courts decide” in the FAQ is, by default, a failure. I’m a programmer, not a lawyer. I don’t give a flying what some jumped up judge in Minnesota might interpret the text to mean, nor should I. If it’s so badly written that it might come down to such a thing (and as in the case of this Oracle ruling, probably not understanding the difference between the product and the API), then it’s not a licence I’m willing to entertain using.

As it could be proved that the team that wrote the code had no sight of the original code, it could not be an infringement.

This was very important, because in the olden days it was quite common to write things in assembler, and if two people write the same API in assembler and they both write their code in an optimal way – especially for a simpler processor such the the 6502, Z80, 8088/86 etc – then theirs a good chance that there will be a number of similarities in implementation; and because of this it was vital to be able to demonstrate that the people who examined the code and documented it’s behaviour had no connection to the people who programmed the clone/replacement other than the documentation that they were tasked to create (which is often reviewed by legal people to verify there is nothing that could be considered “copyrighted” in the documentation). Perhaps the most famous examples were the clone PC BIOSes, but it can also be used for proprietary drivers and such as well. Hmm, didn’t Wine do something similar to present the Windows API without actually containing anything that could be considered Microsoft code?

Which means:

was writing the code on paper

No, one writes a description on paper, somebody else (who has never seen the original code) reads it and rewrites new code from the description.

but this is obviously a non-starter for Toolbox because it cannot be softloaded on old OSes. Or is that no longer a goal?

I trust, asides from major things like CLib, that nobody is thinking of putting too much effort into supporting RISC OS 3.1 in 2019. Too many limitations, too many restrictions. We probably ought to set a reasonable baseline at 3.7.¹²

¹ Consider it a compromise, because I’d say “the Iyonix” ought to be the baseline…

² Twenty quid will get you 3.7 ROMs so there’s no reason to be using 3.6 or, God help you, 3.5…

I still don’t understand the reason for the assertion that one would not be able to produce a soft-load version.

[Removed; I’d misunderstood]

I still don’t understand the reason for the assertion that one would not be able to produce a soft-load version.

I believe that was a reference to not being able to softload the IFR, presumably because it has some reliance on another element of the ROL OS.
However, as you said, IFR would need to be reimplemented anyway and a sensible re-implementation would be one that was softloadable on any OS back to a specified cutoff point (tested) and might work on others (untested)

“It”? Toolbox? IFR? ImageFileRender will have to be reimplemented anyway.

If eveything is reimplemented, we can softload everything. That should be clear anyway :-)

I was interested in a high-level overview of RISC OS 4.xx and SIX Toolbox state to be able to seperate stuff into

• Bugfixes worth having (i.e. things fixed in SIX Toolbox, but not yet in RO5 Toolbox)
• new Gadgets in SIX that would “just work” on top of RO5 Toolbox (i.e. from the A9home 32bit Toolbox)
• new Gadgets in SIX that would need to be reimplemented, but would only need few changes/bugfixes in RO5 Toolbox
• new Gadgets in SIX that would require serious new (OS?) features (i.e. things like ImageFileGadget)

I am not convinced that something like ImageFileRenderer should be in the core OS. But I was also not convinced that the SSL stuff should be part of the core OS, and it happened anyway :-)

I dimly remember Rik Griffin’s “Tabs” and “Tree” gadgets – I think those ran on both SIX and RO5 Toolbox?

I trust, asides from major things like CLib, that nobody is thinking of putting too much effort into supporting RISC OS 3.1 in 2019. Too many limitations, too many restrictions. We probably ought to set a reasonable baseline at 3.7.

I don’t know if “3.7” is an easier target than “3.1 with Nested WIMP”. I am known to gloss over the difficulty in getting the nitty gritty details right of course…

I am following the Stardot discussion about “Arcflash”, an extension to provide in-situ upgradeable switchable OS “ROMs”. This would allow new extended ROMs based on RO3.1, but sensibly extended with more modern stuff to save precious RAM. From a distance, I cannot see much in Toolbox that would not work just fine in an RO3.1/ARM2 context.

Oh good. My 2p: 3.1 is A5000 era, so that’s retro, BBC Micro levels of nerdery. 3.5 however is RiscPC, which is (in my book) merely OLD.

My plan, for that brief glorious moment when we thought we’d bought RISC OS off Acorn, was that RiscPC would always be 3.x, and the new hardware (Nucleus) would start at 4.0… but the developing API would always be softloadable. But then we got gazumped by ROL, which killed Nucleus, and that was that, and the API has been chaotic since. It would be a cathartic process to unify the API again.

And having waded through the ROL stuff, some of the API is fine, some is a bit odd, and some you could simply forget about. ClipboardHolder for example is a better API than the RO5 Clipboard module, but a terrible design. The last time I tried to demonstrate how terrible it is, it broke the tool I was using to show how bad it was (if you ask WimpMon to report all Wimp messages for all tasks and then press Ctrl-C, it will basically consume the entire memory of the computer reporting the wimpslot increases it’s had to make to record all the clipboard messages – there’s a catastrophic avalanche). It should have been implemented using filters.

I am not convinced that something like ImageFileRenderer should be in the core OS

If you think of the OS as a kind of road system, ImageFileRender and ImageFileConvert are a remote cul-de-sac, only connected to anything by the Filer, for thumbnailing. For example, although it would appear to be useful for clipboard handling, it isn’t used for that. (And ImageFileConvert is a revealing misnomer anyway – apart from one parameter to one call which “may be ignored by the converter” it’s not exclusively a bitimage or even visual system. It could convert TextCRLF into Text for example).

Important point – RO5 does not have to design or implement the exact same modules, systems or functionality. A compatibility veneer is perfectly acceptable – it’s the API that should be unified, not the implementation. So although I doubt there’s anything that requires it, it is possible to build an ImageFileGadget module that does not require ImageFileRender but does the best it can itself (I’m not suggesting that, just using it as an example).