Where in the source code are filer windows implemented?

Whether it’s possible to do this with Jeffrey’s optimised algorithm in place I don’t know.

As long as it has a list of which items need redrawing, and a way to (approximately) work out what the item looks like (e.g. sprite used and any “effects” applied like inverted colours), then yes.

The filer was already building a list of which items needed redrawing, the only bit I added was to make sure the list is sorted so that items with identical sprites & effects are drawn in sequence.

If your items are complex objects (multiple sprites, or multiple font types/sizes) then things will be more complicated – e.g. if each item is a slabbed background with a sprite on top then for best performance you’d usually want to draw all the slabs first and then all the sprites on top. The aim being to achieve maximum efficiency for the different caches involved (CPU cache, any colour translation tables the Wimp might be caching, character data in the font cache, etc.).

and so was the Toolbox gadget I mentioned above (anybody know where it is??)

Could it have been the TreeView gadget?

https://web.archive.org/web/20150222054936/http://squeakysoftware.org/gadgets.html

Yay I found it :-)

It doesn’t build though, but getting it working could just be a case of changing some includes.

As long as existing code (Paint/CDBurn/Toolbox gadget/…)

What do you mean by Paint in this context? And isn’t Toolbox caught up in RISC OS 4 vs 5 awkwardness?

Toolbox is being converged at present.

What do you mean by Paint in this context? And isn’t Toolbox caught up in RISC OS 4 vs 5 awkwardness?

Apparently Mr Rawnsley took a turn at untangling things, so daggers are not drawn etc.
So, as Stuart put it, Toolbox is being converged. You never know the result might well have features not present in either version – a bonus for both forks

As for optimization, I think I’ll take a basic functionality first, polish it later approach.

What do you mean by Paint in this context?

The window in !Paint that shows you the different sprites in a file is a filer-like view including mod-cons such as renaming and auto-scroll so might be of interest.

It doesn’t build though, but getting it working could just be a case of changing some includes.

I’ve had a quick go at getting the ResDisplay object to build. It now compiles, but I haven’t tried using it in an application. I put the necessary changes here.

The window in !Paint that shows you the different sprites in a file is a filer-like view including mod-cons such as renaming and auto-scroll so might be of interest.

Is this the right file?

https://gitlab.riscosopen.org/RiscOS/Sources/Apps/Paint/-/blob/master/c/SprWindow

and c.AltRename.

The change log is interesting reading!

* TAB moves rename icon to next sprite.
* Shift TAB moves rename icon to previous sprite
* Ctrl-Return renames sprite and moves the rename icon to the
    next sprite.

The upcoming toolbox unification worries me somewhat. Is now a bad time for beginning a new infrastructure project?

Is now a bad time for beginning a new infrastructure project?

There is never a good time.
Working, along with colleagues, I’ve pushed through more new installs in the last 12 months than in the previous 24. That’s despite me being Covid-sidelined for 117 weeks and despite the “because Covid” don’t change brigade.

Though why would you rewrite the Filer window code in C, when it is quite appropriate in Assembly?

Is it appropriate in assembly?
What does it gain in assembly that can’t be done in C (that then ends up as a binary anyway)?

It would be quite pointlessly reinventing the wheel, as it is already pretty clear and easy to read and work on code, that is well maintained in its current language.

Well, various bits of it are clearer to me in its current form than they would be in C, but that’s my mental block in play. Even I can see that C is a better option.

Though why would you rewrite the Filer window code in C, when it is quite appropriate in Assembly?

If done in the right way, you gain three things: maintainability, portability and reusability.

E.g. you could easily provide common code that could power the Filer itself as well as a much-demanded Toolbox gadget providing a filer-like UI component.

Maintainability? Have you looked at the assembly code in question? It is quite maintainable in its current form, as it is actually cleanly written.

As with all assembler, for ANY CPU, it is wonderfully opaque to anyone who doesn’t know that CPU.
Code in C however, is cross-platform so if you know C you’re on your way.

I expect that a greater number of RISC OS targetting programmers are familliar with ARM Assembly than C,

I don’t. Why? Take your pick:

• OS is massive wodge of assembler, which makes extending it harder, which might be why development is happening, but slowly. It’s also harder than it ought to be to debug stuff.
• Zap, written in assembler, basically has maintenance updates from various people as problems are uncovered. I’ll confess, tracing my way around is hard. Partly unfamiliarity with Zap’s internals, and partly fatigue from endless assembler.
• Impression. It’s great that it is getting more and more ported and that it works nicely under Aemulor. But I’ve seen the Impression source, and I have serious respect to anybody mad brave enough to take that on.

Buy contrast, Mr Pilling probably just did a recompile and fixed up a few small assembler helpers and it was job done for his stuff. That’s pretty much what I did for Ovation…and those programs of mine I’m still maintaining. So while I accept that C can be a real PITA to get your head around, there are clear benefits to it. Even Acorn saw the light, as RISC OS 2 was pretty much pure assembler for the entire OS. Then, little by little, things started being written in C instead.

though how do we assure that C code is kept clean and maintainable.

The same way you do for code in any other programming language.

As the code we have is clean and maintainable

How do you define clean? I would point you at the Wimp for an example of something unclean. A number of files with the name “Wimp” and a numerical suffix. They seem to be broadly topic related, but you’ll find odd functions stuffed in here and there, and an absolute rats nest of conditionals (some with odd names like something to do with chocolate).
Yes, it builds the Wimp, and yes you can turn features on and off, but the code layout seems….messy.

As for maintainable, we’ve been over this numerous times. There’s no problem maintaining a 10K program written in assembler. There is a problem maintaining a 4MB operating system where half of it is assembler.
Plus, the whole 64 bit discussion, because that would involve a ground up rewrite. That’s your maintainability right there.

Charlotte,

Is this the right file?

https://gitlab.riscosopen.org/RiscOS/Sources/Apps/Paint/-/blob/master/c/SprWindow

You probably found out by now, but no, the sprite file windows are implemented, confusingly, in c.Main:

https://gitlab.riscosopen.org/RiscOS/Sources/Apps/Paint/-/blob/master/c/Main

The code’s mixed in with the main() function itself and a few other things. In an ideal world someone would refactor the file window stuff into a c.FileWindow but life’s too short.

The biggest problem with assembler is that you’re pretty much f****d if the ISA changes. Which happens to be fairly soon…

It is a lot easier to translate running code, in compiled binary form, to readable assembler in ones head than it is to C.

That’s probably because the running assembler binary is pretty much identical to the source, only without the labels and other named bits.
The compiler, on the other hand, makes the executable through a mixture of genius and insanity.
But…

Further most debugers allow you to show a dissassembled view of a section of memory, can not get the C to decompile clean like that.

Even RISC OS, with its notoriously mediocre development tools has a debugger capable, when using debug builds, of throwing away the assembler completely and stepping (including single stepping) through the program as it exists in source form.

As to the debuging, what are you talking about.

Debugging applications isn’t hard, just a bit tedious.
Debugging module level code is an exercise in self flagellation (the debugger, working in supervisor mode, can’t debug code running in supervisor mode).
Debugging event handlers, vectors, and service call mechanisms, even harder.
Thank God for DADebug, that’s all I can say.

For source languages of binary executable code Assembly Language has always and likely will always be the easiest to debug.

The easiest language I’ve ever debugged was Visual Basic 5. And that was something like twenty years ago. Things have improved. And over here? Dumping messages to a circular buffer and hoping I don’t stiff the machine before I’ve read the dump… Just lucky I grew up doing it the hard way, so this just seems normal rather than some medieval torture.

though the issues in updating tell me that the code must not be very clean in implementation or structure in order for it to be so hard.

It appears (not looked too hard) that the code is organised fairly well. The problem is that it is devious as hell. I understand that a fair number of issues come from the use of words as being both pointers to things and holding flags about the thing. It might even use running status over SWI calls (in the old API, status was preserved) which would need to be spotted and handled.
It’s also quite possibly the single largest application ever written in assembler, so there’s a lot of it to go through.

and show the other side of this argument

I won’t hold my breath. ;-)

RISC OS is and has always been an ARM OS, not an AARHC64 OS

Two observations – firstly AArch64 is ARM. It’s not the type of ARM we know and love, but it is ARM. And secondly? RISC OS is whatever the rights holders say it is. If it gets ported to 64 bit and ROD are behind that transition, then it’s RISC OS, just like it’ll say when it goes “beep” at boot.

So your argument has already come and gone,

Uh huh. Okay…

But back to topic, what is the most accessible “gadget” to do the nitty-gritty of wrangling icons in a filer window like way? Is it the new !Paint stuff?

And for that matter, is there any sort of guide to available gadgets, or is it sporadic?

I have been slowly going through the sources from the tarball I downloaded the day of the 5.28 release, and bit by bit documenting what source modules what functions are in, and what source modules call what functions.

Whether or not the future is C, this sounds really interesting! :)

Charlotte:

But back to topic, what is the most accessible “gadget” to do the nitty-gritty of wrangling icons in a filer window like way? Is it the new !Paint stuff?

The file icon code in Paint is fairly simple to read but it’s also fairly integrated with the data structures for the sprite files and mixed up with the other code, so as it stands it’s not really a gadget that can be lifted out to readily use elsewhere. That said, there’s nothing to stop someone extracting all the relevant functions into a new library and turning the sprite file linked lists into something more generic.

Rick:

[Impression is] also quite possibly the single largest application ever written in assembler, so there’s a lot of it to go through.

This made me think of Braben’s Frontier: Elite II but Wikipedia says that was about 250,000 lines of assembler so I suppose that’s “only” around 1 megabyte! How big’s the code for Impression Publisher? It was always out of my league.

How big’s the code for Impression Publisher?

The actual RunImage file is a little over half a megabyte, but it does also use a lot of ‘helper’ modules, which would more than double that size.

This made me think of Braben’s Frontier: Elite II but Wikipedia says that was about 250,000 lines of assembler

How on earth does anyone write 250,000 lines of anything, let alone assembler? The mind boggles!