Horizontal Scroll Bar for Boot/Run-at-startup

Configuration Boot-at-startup and Run-at-startup and possibly Add-to-Apps could benefit from a horizontal scroll bar so that the full path location of a program can be seen. Simply editing the Res file for each of these can be made to create another scroll bar. Could this be implemented in future HardDisc4 releases please?

Simply editing the Res file for each of these can be made to create another scroll bar.

If you have edited copies you could let ROOL have them and save them a short while…

Make it a resizeable window with normal scrollbars.

Fixed size scrolling regions within windows are evil!

Fixed size scrolling regions within windows are evil!

Just sounds so Windows…

Just sounds so Windows…

yawn

Yes – I agree – it’s not the best solution but lets be practical – this modification can be simply and quickly implemented without incurring additional programming time which would be better spent on higher priority stuff.

The best idea would be to copy the system used by RISC OS Select which I seem to remember uses a resizeable window.

I seem to remember uses a resizeable window.

A dialog with a scrolling pane can be resized if you’re prepared to do some fancy footwork: http://twitpic.com/bcngkq/full (no ‘nested Wimp’ stuff there)

Very nice but surely your suggestion would involve quite a bit of extra programming. The solution I’ve highlighted is not the best by any means but is easy to do by editing an existing Res file.

That would depend on how complex the parent window is, it could be as minor as scrolling the parent to keep its OK button in the right place. Having just checked it seems the RISC OS 4 windows already work like my example(!), I’d never noticed (I edit my boot sequence by hand).

Having just checked it seems the RISC OS 4 windows already work like my example(!)

4.02 or later? i.e. Code that probably exists in the ROOL archive or in the unfortunate sealed source box of ROL?

If it’s the latter then as per Chris Evans comments elsewhere – likelihood of ever using those ROL developments on new systems is approaching zero and therefore a block of replication work for ROOL.

4.02 sure doesn’t do that in the Boot at startup window, just checked.

4.02 sure doesn’t do that in the Boot at startup window, just checked.

With the ROL toolbox loaded I presume. In which case it’s bad news time.

I hadn’t gone upstairs to check on the RPC

I used 4.02 plus !RO4INSTAL’s !Boot structure, so I’d assume so.

@nemo
I suspect the answer is yes, but is that a Select version?

Oops, just realised Liverpool ties¹ and the match is on, and probably the net access isn’t on the lap with a TV handy.

¹ Higsons devotee or not?

4.39 “Adjust”. I didn’t willingly purchase RO4, it came with VirtualRPC, which is mostly very good (once hacked around with).

Steve worried:

If it’s the latter then as per Chris Evans comments elsewhere – likelihood of ever using those ROL developments on new systems is approaching zero and therefore a block of replication work for ROOL.

Come on now! The engineering involved in resizing the parent window and potentially moving a couple of icons in response to the pane resize is trivial. I realise that 0+k > 0 but this isn’t worth worrying about.

It’s not like I suggested writeable icon text selection ought to be done. That’s less trivial (but very necessary).

Come on now! The engineering involved in resizing the parent window and potentially moving a couple of icons in response to the pane resize is trivial.

The most I’ve ever done in programming on RO is a chunk of BASIC that sorts mail into appropriate directories, created on the basis of the user id in the outgoing mail, and then repeatedly calls PopStar to send the mails using the appropriate user credentials in each case.
Oh, and twiddling with some open source stuff to create a blackhole DNS querying tool because the stuff in RO didn’t want to do what I was trying to do. After correspondence with Frank de Brujn he included something similar in function in AntiSpam. I believe his was rather better a job.

So, determining how easy or hard the changes would be probably couldn’t be put in my CV (I have a manager that knows all about everything so he could be the worlds authority)

If it’s easy then fine, I will wait all the way to the end of the month for the change to appear. :^)

Serious comment though – I think a list of the specific features that are needed, as opposed to just wished for, might be rather useful for ROOL.
As I referred to the ROL source arriving in the ROOL repository doesn’t look like a likely event so it’s move on time.

Serious comment though – I think a list of the specific features that are needed, as opposed to just wished for, might be rather useful for ROOL.

Define “needed”.

Here are some I remember, and I’ll outline an idea of my own below.

• Multicore support.
• It might sound like a wishlist item, but wouldn’t the ability to access extfs partitions be useful to us?
• Linux media players can do 480p without a problem and some platforms 720p. We struggle with 320p due to software decode without GPU ‘help’. Is this something we might be able to resolve, at least on the RPi?
• “Is my scanner/printer supported?”
• There’s a long list of filesystem stuff by Sprow, who suggests bounties for such things as removing the 2GiB file limitation, partition support, 64 bit file pointers, journalling, >255 file pointers, non-blocking, etc etc.

There are many things RISC OS needs, I think the list you’ll get depends upon who you ask. (^_^)

Here’s my suggestion. Transparent UTF8 capable desktop. It is to work as follows:
If you load an “old” application, any around now, it will behave as it currently does relying upon the current language/country setting.
If you load a “new” application, flagged as UTF8-aware by a bit in Wimp_Initialise, the Wimp will assume that any text given by the application (SendMessage, template text, etc) is in UTF8; likewise any text given to the application will be UTF8. This means Wimp_ProcessKey will expect to see a word, and Event_Keypress will provide a word.
[the hacky multiple-keypress-events method would cease to exist]
The is not a compatibility problem as an application that does not say it works in UTF8 would have “old behaviour”. There will be a new SysKeyPressed event and all the “extra” keys (Del, F1, MediaPlay, etc) will be placed there. This, again, is not a compatibility problem as it is behaviour specific to the UTF8-compliant Wimp. Note, however, that I would keep special keys using their current (>256) codes because reassigning everything would just cause annoyance. If the existing codes are retained, existing key handling code can be easily recycled.

There will be a helper module, with a name like “UTFTranslate” that will translate UTF8 to Latin1 (etc) with anything not understood being replaced by question marks – so “animé” (UTF8) will be seen as “animé” (Latin1), while “涼宮ハルヒ” (UTF8) will be seen as “?????” (Latin1).

This is only a high level GUI thing. I don’t think it is either worth it or feasible to get the underlying OS to cope with UTF8, like in the command line. The DOS command line doesn’t do it either, while Windows GUI can, so it’s a reasonable place to draw a distinction.

There shouldn’t be a problem with UTF8 filenames as the <xxxx>Filer incarnations won’t be flagged as UTF8-aware so they will receive older behaviour. Upon such time as the underlying filesystem can cater for UTF8 filenames, the relevant Filer(s) can be updated.

If/when I get around to getting myself the ROOL DDE and a buildable version of RISC OS, I plan to see if I’m up to hacking around the Wimp to attempt an implementation of this. Wish me luck, light candles, etc.

Justifications: Firstly, we need to enter into the modern age. My Zen media player and phone both tell me that I’m listening to a song by “鬼束ちひろ”. Chances are if you are reading this under RISC OS, you’ll see question marks, char-code markers, or nothing at all. The desktop needs, in my belief, to move forward to an API that goes beyond Latin1, Latin2, LatinX to embrace “characters” as an entity, not little subsets. The other day I was in the ludicrous situation of trying to load a katakana font in OvationPro but it only worked while the system was configured Latin1. It went wrong when configured UTF8.
However, the second important point, this expansion must be performed in a way that provides minimal (preferably zero) disturbance to existing software. There isn’t one among us with the ability to demand everybody rewrite their software. This isn’t a recompile-it job, the change is more fundamental than that. So retaining backward compatibility is every bit as important as going forward. The only thing I plan to get rid of is the use of multiple keypresses to simulate UTF8; if an application can deal with it, then it should do it properly.
Thirdly – no, setting the system to UTF8 is not a solution as this is global and will, accordingly, affect stuff currently running. To be honest, the whole country/language/Territory system needs to be ripped out and rewritten with the benefit of hindsight. This is something I may look at once I’ve broken the Desktop. ;-)

That’s my plan for something I believe RISC OS needs. I’m sure some will disagree and some will say “balls, RISC OS needs <insert item> before any of that!”.

Over to you…

Define “needed”.
Here are some I remember, and I’ll outline an idea of my own below.

Wish list omitted.
Grump away but until the base stuff is done, the rest is wish list.
The true base stuff is probably defining what is needed rather than the actual implementation…

Sorry Rick but the conversation was about those little (or not so little) items that ROL created/modified that are locked away in that closed source box.
The “needed” bit was about those things that people say “well Select has x, y, z and the ROOL version should have it as well”

The question is: What does the OS REALLY need from that stuff?

Not wish lists, not I think this is whizzy wonderful, what does it need?

Leap ahead all you like in your thoughts, but unless you provide a path forward for both the "I’m not buying that ROL Select stuff crowd AND the I think ROL are wonderful crowd you have lost. Because, simply put, the majority of existing RO users need to be on board for the whole thing to work. New enthusiasts will simply wallow around awhile and wander off without that existing user base.

It might sound like a wishlist item, but wouldn’t the ability to access extfs partitions be useful to us?

It would, but I think it should probably be an add on module, (since it would probably be gpl.) Although it would be nice to be able to have in the core system.

Linux media players can do 480p without a problem and some platforms 720p. We struggle with 320p due to software decode without GPU ‘help’. Is this something we might be able to resolve, at least on the RPi?

My Pi and 2 dedicated media players do 1080p no problem.

But again, wouldn’t this be an add on to the OS?

“Is my scanner/printer supported?”

Again, not a core thing.

There’s a long list of filesystem stuff by Sprow, who suggests bounties for such things as removing the 2GiB file limitation, partition support, 64 bit file pointers, journalling, >255 file pointers, non-blocking, etc etc.

I think the non blocking part is the most important for sorting out performance issues. Apparently the existing API can be extended from 2GB to 4GB by fixing a signing issue. Beyond that it would need a new API. I would hope the new API would be non blocking. I don’t see there is much point making ADFS support bigger files than 4GB, unless it is really easy. We would be better off using NTFS, EXTFS etc (or an NAS). It would be nice to have a module that provides for large files on old filesystems though. They could be made into folders of parts of the file, like CDVDburn does.

Here’s my suggestion. Transparent UTF8 capable desktop.

I like this.

I’m listening to a song by “?”. Chances are if you are reading this under RISC OS, you’ll see question marks, char-code markers, or nothing at all.

It displays under Netsurf, but it’s not going to quote.

So retaining backward compatibility is every bit as important as going forward.

I think this is also the case with multitasking, (and probably non blocking file access).

There should be a new set of APIs that provide the more controlled access to the system (PMT, non blocking file access, etc.) But these should only apply for new programs (and the parts of the system that get modified to take advantage of it.) You run a new program and it doesn’t stall the system. You run an old program and it freezes the system just like now. (And it’s generally ports of programs designed for a PMT system that do this, anyway.)

This would have the added advantage that those who want the ability to grab the whole system just use the current method. I have noticed quite a few posts where this ability is beneficial for certain purposes. (I think this would be why I found CDBurn far more reliable than any Windows 9x system, because the machine was allowed to do nothing else.)

but I think it should probably be an add on module

Not to be an ar** <grin> but where would you make a distinction between OS module and add-on module? Isn’t my suggestion sort of like a Unixy version of DOSFS?

My Pi and 2 dedicated media players do 1080p no problem.

Thanks. I knew the Pi could do HD, but I didn’t know if it was 1080i or 1080p so I just left it. It does 1080p – I’ll remember that.

“Is my scanner/printer supported?”
Again, not a core thing.

I know, but part of the “installation” contains the printer driver setup. Isn’t it going to be logical to look in there and find……..some printers so old you probably can’t even get spares for them off eBay. Is Printers not a part of the ROOL “product”? Again, like RISC OS itself, it is highly modular and can be expanded by others.

I don’t see there is much point making ADFS support bigger files than 4GB, unless it is really easy.

We’re moving from a 32 bit pointer (4GiB-1) to a 64 bit pointer (>4GiB).

I should point out – if the filesystem doesn’t support more than 4GiB, it would not be possible to hold DVD isos – a DVD-R is 4488KiB (or 4.7GB (denary)).

I have noticed quite a few posts where this ability is beneficial for certain purposes.

Certainly. There is a certain level of predictability with RISC OS. I shall give you an example with Windows that happened earlier today. I was pulling the latest Chuunibyou (a 200MiB download). From time to time Windows freezes with the disc light on. I don’t know what this is as my system does not use a swapfile (not a good idea with SSDs!). So this “freeze” can take 20-40 seconds. I’ve had ProcessExplorer running when this happens and there is no spike on the CPU activity. It is as if that period of time simply does not exist, so I can’t blame Firefox or (file)Explorer or Avast! or…
Well, this evening during the download the machine did that for one of its longer periods. During which the download was aborted and had to be restarted from the beginning. Now imagine if I had some widget plugged into USB that had digital I/O at the other end hooked to some sort of hardware device that received controls from the computer. Say, for instance, I am developing a production line machine that bashes dough into croissant shapes. Would you want erratic pauses? Would you want nothing to happen when you hit the emergency stop because the host computer hasn’t noticed? What if there was a belt-driven thing that whizzed back and forth (think of an automatic loom) to pull the dough into shape. The motor fires up to take the thing back to its home position (detected with hall effect sensors) – what do you suppose would happen if the host computer goes into Helen Keller mode for thirty seconds, with the motor having already slammed the “thing” into the side of the machine before you finished reading this sentence.
At least under RISC OS, an abort mechanism can be implemented as a module to always be active (I noticed my BeagLEDs ticker LED kept running even when the machine had “crashed”), so there’s a last line of defence in software. However if you write your own code for the machine, you can know that complex timing is possible under RISC OS because the OS is happy to back off and get out of the way.

This, perhaps more than anything, is something we ought to be shouting about from the rooftops when it comes to the RaspberryPi. Want to play Taylor Swift songs by bit-bashing the audio data to a GPIO (PCM, maybe even S/PDIF!)? With RISC OS and a Pi you can probably pull it off; and reliably so. Maybe even in BASIC with critical code being some wodges of assembler. While Swift is a rather “because I can” example, you can expand upon this to all sorts of devices that require a lot of processing power but demand responsiveness. Essentially, RISC OS has the ability to turn a Pi into a Great Damn Hero version of the microcontroller, offering microcontroller-like attributes with the processing power of a full system. Consider something like a quadricopter (one of those “about a metre-across” ones) with an on-board camera and a Pi. You could use the remote controller to control the camera and the Pi would translate this into how to fly the quadricopter to make it happen, with enough responsiveness to keep the whole thing fluid. All a bunch of random ideas floating in my head, suffice to say I’d be wary about using other operating systems. I know Linux can provide realtime-like facilities, my PVR runs Debian on a 200MHz ARM and it can keep up 640×480 @ 25fps video recording (though it takes several seconds for the command line (via telnet) to catch up); however I would imagine coding that sort of thing for Linux would be considerably harder than the same under RISC OS; and I wonder if Linux has a mechanism to push the OS itself out of the way for when you know you need to count every cycle…
Perhaps one of RISC OS’s weaknesses on the desktop is one of its strengths in an embedded device?

Sorry Rick but the conversation was about those little (or not so little) items that ROL created/modified that are locked away in that closed source box.
The “needed” bit was about those things that people say “well Select has x, y, z and the ROOL version should have it as well”
The question is: What does the OS REALLY need from that stuff?

All further quotes from: http://select.riscos.com/SelChanges/s4changes.html

I’m going to skip Toolbox stuff, as I don’t use Toolbox so don’t know if their changes are good, okay, or in a different direction…

The Kernel has been hugely restructured, abstracting a great amount of the functionality in to support modules.

How does this differ from our RISC OS? I presume this is talking about abstration as in “OS_Byte” moved out of the kernel, rather than using a HAL? It is a possibility, but it is a necessity?

Debugging support has been improved – via the BTS [Back Trace Structure] system, BTS tools and DiagnosticDump module,

Something we could add? Granted, the C backtraces are not terribly helpful to ordinary people. Maybe some sort of “snapshot” mechanism might be an aid to developers? But, again, it is nice but is it necessary?

* Checks are used ensure the consistency of the AIF header on Absolute files. This helps to improve the stability of the system by rejecting code which is malformed.

…which might not be such an issue if the OS was hardened a little more so a bad program will risk crashing the program and not the machine.

BootMenu

Harinezumi could probably fake some of this stuff. All we need is a version that runs as a module and kicks in before the OS starts the command line interpreter… Again, nice but is it necessary?

ColourTrans

As discussed earlier, this possibly needs to be rejigged to handle gamma and such?

One thing I noticed when making Harinezumi – there are commands to convert palette entries (&BBGGRR00 IIRC) to GCOLs, but there isn’t a SWI that I could see to return the palette entry from a GCOL. I mean, what colour is GCOL 47,2 ? There’s some sort of OS_Word to do this. Shouldn’t there be a version in ColourTrans?

DHCPClient

Our DHCP needs to be modified as followed. I am assuming that the Pi’s hardware can return whether or not there’s a heartbeat (cable connected)? If there is, attempt to do a DHCP configuration. If there is not, revert to preconfigured static IP address. This would mean that DHCP can work on the Pi out of the box (most recent routers should respond to the DHCP request), but it won’t hang up for ~30 seconds when nothing is plugged in.

DisplayManager
* Added support for display device selection.

ROL’s supports multiple displays? At the same time? Same stuff on each, or different? That’d be dead useful for debugging to run the oh-look-its-risc-os-two debugger on one screen, with the “live” system on the other.

FileCore
* Added support for DiscOp64 – support for large discs.

Looks like they didn’t attempt non-blocking either.

Internet

Looks like a lot of stuff was fixed here. Important?

Kernel

Now, after all those image convertors and stuff, we get to some meat.

* Removed support for Mouse/Pointer.
* Removed printer buffer from Kernel.
* Removed the mouse buffer from the kernel (on NoMouseBuffer).
* Removed text character output.
* Moved the point rendering out of the kernel.
[long list of stuff]

I can sort of see what is going on here. It looks like they were stripping RISC OS down to a microkernel with all of the cruft provided as separate modules. I look at that list and think “Oh my God!”, and then I look at it again and think “Oh. My. God.”.

Some of it seems so obvious. I mean, why is the kernel in charge of printing text or doing stuff like OS_Plot?

* Reduced period between VRAM rescue checks to 5 seconds.

Eh?

* Added OS_Word time setting call using 5 byte time.

Useful, but to be honest OS_Word and OS_Byte are anachronisms. Obviously they will need to be retained for compatibility, but it might be better to read/write the clock and NVRAM with something other than OS_Byte/OS_Word. How about OS_Time? Or maybe better still, Territory_Clock to fold in the option of “UTC or Local”. Likewise for NVRAM.

* Removed the RTC system, now living in an external module.

This is in line with kicking ’most everything else out. Though, as has been observed on the Pi, perhaps if the RTC is not detected, it will flag this and return generic data on reads and ignore writes instead of periodically attempting to access hardware? Might be useful to make this a replaceable module, so can support whatever methods may be designed for the Beagles, Pies, etc, just by having the hardware come with a suitable module…

* Removed redundant keyboard processing, including R/T/Copy-reset.

? You can’t force a reset-NVRAM on ROL’s version? Granted, it would solve a lot of nonsense in the kernel, but if your CMOS is shagged up, how do you go about fixing it?

* Increased IRQ stack size to 16K.

What’s the current size? How full is it normally? What happens if it overflows?

* Updated CAM map to be inaccessible in USR mode.

There’s a pile of stuff that ought to be inaccessible and/or read only in USR mode.

* Updated zero page to be read only in USR mode.

…it wasn’t already? I thought 3.7 or somesuch did that?

* Added support for early initialised modules.

What does this mean? Early initialised?

* Abstracted NVRAM calls to external module.

Along with RTC mentioned earlier, this would be a useful thing for the various third-party options for the SoC boards.

* Updated mode 7 to be 640×480 in 256 colours.

Whoo – Level2! ;-)
People still use MODE 7?

* Tentative support for touchscreen devices.

Interesting. I’d have thought a new API would be necessary; for instance I could not easily support a graphics tablet with OS_Mouse’s mechanisms (how to report pen pressure?), touch devices have a fair few additional possibilities. In terms of necessity, it can be thought about later…

RedrawManager – (new module)
* The RedrawManager module provides, together with the FilterManager and recent versions of the Window Manager, a mechanism for drawing into a window as part of the Window Manager’s redraw process. This allows clients to transparently implement complex rendering without requiring the application to be updated to explicitly call the rendering routines as part of their redraw loop. Complex gadget redraws are made much simpler through the use of the RedrawManager. With RedrawManager, Gadgets may redrawing their content without any application-specific support.

A week or so ago we were discussing a compositing GUI. Something like that?

Not “necessary”, but interesting to note.

SpriteExtend
* Added functional support for CMYK and YCbCrK JPEGs.

Not necessary, but are progressive JPEGs supported these days?

TaskWindow

A worrying number of fixes there…

[TerritoryManager] * Updated SWIs to default to UK territory when the configured territory is requested, but that territory is not present.

Seems logical.

WindowManager
* Rationalised Icon Transition masking in face of the multitudes of broken libraries that it seems impossible to patch reliably.

Head, meet wall.
This is why backwards compatibility is important. To try to implement such compatibility with “autopatching” is always something of an exercise in self flagellation…

Seems like a lot of Wimp stuff was to do with Icon Transitions.

Okay, that’s all for now. I’m beat.

But, apart from the sense of stripping down the kernel, and moving out CMOS/RTC code to separate modules (especially since modern devices don’t use the Acorn method here); there are a lot of “good idea”s but I’m not sure how much is absolute necessity. I suspect the skipped-over Toolbox stuff might be seen so by some.

Maybe best to ask an actual RISC OS 4/6 developer – what do you think RISC OS 5 needs to support that it doesn’t now?

Those are just the changes from, I believe, Select 3i4 (4.39) to Select 4i1 (6.02 Preview, I think).

Anyway, the code to handle resetting CMOS could safely be removed from RO6, given that there has never been an Adjust (ROM) release of Select 4, 5, or 6. You would be booting RISC OS 6 from a 4.02 or 4.39 ROM, and that ROM would have reset code.

I am assuming that the Pi’s hardware can return whether or not there’s a heartbeat (cable connected)?

Link layer detect (OSI model L1). Is the NIC connected to another L1 interface?
BTW The layer “boundaries” are as fuzzy as ********

Not to be an ar** but where would you make a distinction between OS module and add-on module? Isn’t my suggestion sort of like a Unixy version of DOSFS?

The issues I was thinking of are that the OS should be designed to have and use plug in filesystem formats. And that unless you were writing from scratch or using a BSB licensed source, it would be GPL, giving the same issue as FAT32FS.

I should point out – if the filesystem doesn’t support more than 4GiB, it would not be possible to hold DVD isos – a DVD-R is 4488KiB (or 4.7GB (denary)).

It would not be able to hold full capacity DVD ISOs, (but 4GB is much better than the current 2) and FAT32 is the same. Which is why I think a driver that fakes big files by storing folders full of 2 or 4 GB chunks (similar to the way longfiles faked the names) would be good. (And the files would survive copying by non aware utilities.)

Any effort spent making Filecore support the bigger files would be far better spent porting EXTFS or even NTFS.

* Checks are used ensure the consistency of the AIF header on Absolute files. This helps to improve the stability of the system by rejecting code which is malformed.

I thought this one was a good idea. (Because it can be turned off, if you need to run a program that has a bad header.)

bq.Internet
bq. Looks like a lot of stuff was fixed here. Important?

I did notice my Iyonix was much poorer at doing network stuff when I first got it than my RPC. (e.g. streaming internet radio was rubbish.) It doesn’t seem to have such problems not, so I assume lots of similar work has been done.

Also I notice the page is changes from 3 to 4.

There are goodies from previous selects too. Notably the image render system. (And the cosmetic stuff)