Programming IDE for RISC OS (CodeCube Cloverleaf project)

A visual diff interface would help greatly, so we can clearly see what is in each potential PR.

Don’t forget we have Hariet Bazeley’s Sidediff. If it doesn’t do exactly what’s wanted, it might provide a basis.

I use VS Code to compile TBX GUI applications into a running RPCEmu under Linux.

The most important feature for me is, when you hover the mouse over an expression, it shows its class members and comment, and you can right-click on it to jump to the class definition in your code, or in a library.

So if StrongEd could get that, this would be great.

Debugging is not so important for me, better avoid errors than trying to find them.

And even under Windows or Linux, debugging of GUI applications is not too comfortable.

https://code.visualstudio.com/

@Jean-Michel BRUCK

Thanks for your comments. Your code for tree view might be helpfull for our project viewer. (Actually I used your screenshots to make the mokeup of the IDE :-D )
Also to use the DDE standard file/folder structure as template makes sense.
I was also a Borland Delphi user before so I have that in mind when I am talking about an IDE.
I will check out the programs you mentioned.

For a project like Stefan’s, it would be good to have specifications so
that everyone is interested.

If you have any ideas about specification then I would appreciate if you write them down.
As I am currently not an active RISC OS programmer I might miss some important stuff.
That request is directed at everyone!

@everyone

If you missed the info about VIM on RISC OS:
VIM on RISC OS on ROOL

I think you would find opinions quite divergent between those groups.

And also between groups who favour one language over another; C++, BBC Basic, C, Python, Lua, … ;)

A good example how new programmers struggle you can see in Simon Ayers video:

Here’s another practical example, James Hobson struggling with WIMP programming (ten episodes).

Another perspective gleaned from watching these videos isn’t necessarily the need for an IDE, nice to have one, but access to relevant information.

An open source Operating System needs to have a set of tools that work out-of-the-box. For example: Yesterday I took !Sourcery for a spin and I couldn’t get GCC to compile a Hello World! I concluded, although I did make progress that !Sourcery was written for an older version of GCC.

@Stefan Fröhling

Thanks for your comments. Your code for tree view might be helpfull for our project viewer. (Actually I used your screenshots to make the mokeup of the IDE :-D )

I built Diderot for my use and thought it might be of interest to other people.
I will send you my latest version, it’s in C++ with the CathLibCPP library (A 32-bit version that I recompiled, hosted by Alexander Thoukydides)
Not very standard, but this is due to the DDE which has not yet upgraded the C++ and Cfront compiler.
On the other hand Cathlib is very efficient, I appreciate having the STL under RISCOS.
Delphi is the Pascal version, I have used Builder the C++ version. and learned C ++

I think it would be a good thing to group together the various
applications / utilities used for development and to be able to access them quickly. Easy with RISCOS just looking at them.

It may not be worse to have several applications that do their job properly, rather than a big application wanting to do everything and why not use what is already done !, it is not the work that is lacking !

In my last message I forgot !Reporter and the debuger files that go with it, they are very useful.

Also to use the DDE standard file/folder structure as template makes sense.

I think this is a good standard with Makefiles. Not everyone likes it :-)
I also use the DDE Install directory. easy with makefiles.

I started from the examples supplied with the DDE and that formed the basis of my applications. With Borland you build a project, it asks you for the type of project and loads a typical application just bychanging the names.
This is what I am doing today by changing the names manually.

From Lothar

The most important feature for me is, when you hover the mouse over an expression, it shows its class members and comment, and you can right-click on it to jump to the class definition in your code, or in a library.

We have StrongHelp help with the F1 key, it is very efficient. Do not hesitate to write manuals …
For the class definitions I found a CCDOC utility which I recompiled with !GCC.

CCDoc builds HTML files from the application’s .h files, if these files have been documented, which is a very good habit especially if you want to produce reusable code.

There is an example in the Zccdoc directory of the source of !Diderot.

“download”: https://jeanmichelb.riscos.fr:443/Temp/DiderotSce.zip

Hoping the file is complete, I can provide CathlibCpp for those who want to compile with DDE.

CCdoc de Joe Linoff

I hope I can be understood, and this is just the way I work.
—
Jean-Michel

@Jean-Michel BRUCK
Thanks again for infos and links. Will check that out.

Hi all. :)

As my video was one of the sources cited in the opening post by Stefan, I thought maybe I could offer a little bit of my personal perspective.

I wouldn’t say that an IDE was completely necessary (for the time being), but obviously it is convenient having the project management, build options and window design simplified. I don’t think IDEs are being pushed for beginners and rapid application development these days as much as they used to be. More the libraries themselves that get people off and running quickly.

But from my perspective, as someone who used RISC OS donkeys years ago and am coming back, now as a C and C++ programmer from other platforms (mostly Windows), I am finding there are more basic hurdles to getting started (which is what hopefully my videos will document as I get through them). Some can be fixed, and some are just because RISC OS does things differently so they need to be learned:

- The text editors are hard work. I’m starting to like StrongED but it isn’t easy to use and it took me quite a few tries to be able to stick with it and not get fed up. If I only have a few hours spare to try something I can’t really afford to spend 20 minutes or more figuring out the editor. Over the years I had tried various things and given up before I was able to get any meaningful progress. The reason the first big project I’m going to work on is a very basic VSCode-type editor is just to keep a bit of familiarity for new people to the platform.

- DDE – The C++ compiler probably should be deprecated. But more frustratingly, I can’t seem to be able to install DDE and get it to build the example programs as AMU gives errors. I think it needs some jiggery-pokery involving the OS build system but I haven’t figured it out and frankly as a ‘commercial’ product it should probably work out of the box! Also, I found it difficult to figure out how to use the shared makefiles – where are they documented?

- GCC – It seems to work pretty well. I’ve built a few small test apps with it easily enough. That said, (as referenced further up the thread) I wouldn’t have got there anywhere near as quickly if I hadn’t followed on from James Hobson’s tutorial videos (for setting up environment variables, etc). Not sure how I would fair if I tried porting some reasonable sized project from a different platform (but frankly I am nowhere near that stage at the moment). Also, are there any best practices for RISC OS GCC projects (like project file layout, build files, etc)? I’ve seen there are projects that are auto-built and stored on riscos.info. Should new projects be following a template that would work with the Autobuild system?

The reason I started the video (and am finally getting round to following it up more regularly), is because this information is difficult to find so I decided if nobody out there has made videos documenting the process of writing applications on RISC OS then I will. A case of ’I’ll suffer so they don’t have to’.

I also (as a learning exercise) was going to try and build my first apps in C++, building up a sort of simplified version of the VCL library from Borland (again, mentioned above), so that it looks familiar to people watching the videos coming from C# or something like that. I’ve even written a basic coding style guide for my videos to make it look as simple as possible (even though that isn’t how I wrote code for my day job).

Basically, in my humble opinion what the platform needs most importantly is documentation/tutorials and someone to hold a beginner’s hand. That’s why I think the Wi-Fi Sheep videos are important. They can simply introduce people to the platform. Just need similar videos to that for the programming side (and ideally not in BASIC).

It seems that there are a few people commenting similarly in my video. I’m working on following it up now (hence being back nosing on the forum), so hopefully I can help address some of those issues, if I can find out the answers!

Kind regards, Simon. :)

- DDE – The C++ compiler probably should be deprecated.

I think you spelled deleted wrong. It’s based on CFront, the same ancient C++ to C translator I was using at UCL back in 1987. It copes with such a small subset of the language it can’t really be classed as C++ by anyone that has been using the language in the last 20+ years.

So if you want C++ use g++.

It copes with such a small subset of the language it can’t really be classed as C++ by anyone that has been using the language in the last 20+ years.

Yes, I leave the conclusion to Alexander Toukydides (! PsiFS), email dating from 2006:
“Miles Sabin has done a superb job within the constraints of Cfront, although somefeatures are more a proof of his skills than useful in practice. I have used CathLibCPP very successfully in many of my programs, especially in conjunction with Toolbox. However, I would have thought that it would now be better to use GCC.”

I continue to use CathLibCpp car j’utilise le DDE, but also g++, I used it to recompile CCdoc, very useful tool to have information on the classes of the application.

I am coming from a similar place to Simon, I think, but although I am used to things like Visual Studio only day job, I don’t have much gripe with StrongEd. I think much of that is just down to the editors being different.

I agree that the lack of examples and tutorials is the killer. If I wanted to learn how to write a modern ‘web app’, using a front-end framework like VueJS, I know I will find boatloads of help from documentation, tutorials, discussion forums, stackoverflow etc. This just isn’t there for RISC OS.

I have found the web accessible sources to RISC OS itself (on github for the Linux port, but also here for the official gitlab repo) to be quite helpful. With a decent browser, I.e. my tablet, I can browse to find all sorts of samples. Harder-going than it should be, but better than nothing.

I have never done anything with C++. Not sure what language would be good for general purpose apps… Python? JavaScript?!

Simon makes a good point in that RISC OS really should work out a standard for how files are organised, Makefiles set up etc. On other platforms, once you have the dependencies, building is as simple as typing ‘make’. On RISC OS there isn’t really a consistent way to find libraries etc. Too often people have written their own convoluted build systems using bits of Obey, BASIC, etc which often only work on the machine of the person who wrote them.

It would be good to put some guidelines in place so that you can fetch the right pieces (eg via Packman) and things will ‘just build’, using either DDE or GCC depending on what you have. It would additionally be good if that worked when cross-compiling too, so no need to write a separate build script. (The ROOL makefiles handle both, so that wouldn’t be a terrible starting point). Being able to ‘just build’ would also solve the issues when code needs to be rebuilt periodically, because it would be easy to ‘turn the handle’.

While we are murdering parts of the toolchain, can I also volunteer !Make? It emits bizarro makefiles that are no use to anyone. Replacing it with something like Sourcery that knew how to write proper Makefiles (according to the above standard) would be a big improvement.

While we are murdering parts of the toolchain, can I also volunteer !Make?

Well, its own manual says not to use it, so…

@Simon Ayers

Thanks for your post video comments :-)
This only confirm for the need of a simple programming environment with cross platform usability (eg. editor handling).
And some cleaning or structuring on RISC OS. (file structure and libraries)

As a seasoned .. (old!) developer, here’s my take.

Even on linux I often still tend to edit text in an editor and compile it in a shell. I might be in a minority but that’s how I tend to do it. However eith editor throwback that’s not actually quite so bad on RISC OS anyway.

However, there are other bits of an IDE that I find very useful. The ability to “go to definition” / “go to implementation”, find all uses of this symbol in this (or all) projects. Having all the files in a project easily accessible from the editor (it’s much easier to jump around them when they’re just a click away) The little “hover over” that tells you the paramaters of a function to remind you what order to put the arguments in.

There are probably others. Pehraps my point is we don’t need to go full Visual Studio to bring some real benefits. Getting people to try RISC OS is a battle enough, getting them to try to develop on it many times more. The learning curve is near vertical for a lot of stuff.

Too often people have written their own convoluted build systems using bits of Obey, BASIC, etc which often only work on the machine of the person who wrote them.

Half the time they don’t even work on the machine of the persons who wrote them .. :)

I think some more modern development tools would be great but I also think just having some templating tool would be useful for new comers to RISC OS development. eg The Microsoft botnet CLI tool makes it really quick to get a project first up as you just type
#dotnet new console
#dotnet build
#dotnet run
Having a quick way to get a new project setup without needing to do all the config would be a great help to existing developers coming from other platforms.

Having a quick way to get a new project setup without needing to do all the config would be a great help to existing developers coming from other platforms.

Shared Makefiles come as part of the DDE, and come with templates for common projects…

https://www.stevefryatt.org.uk/risc-os/wimp-prog/a-better-way-to-compile

This is mostly a question for Fred. If you have some experience cooking up new modes for StrongED you can easily add new icons to the smarticonbar which will do things when you click on them. But can you make the appearance of that icon change when the contents of the StrongED window change? For example you might want an icon that looks like a cross change to a tick if the text in the window parses correctly for some user-supplied parser. A more sophisticated form of feedback would be for StrongED to colour the longest prefix of the text that satisfies the parser green, say, leaving the postfix red. Better still, if we are thinking of IDEs, is for StrongED to put up smarticons, one for each non-terminal in a user-supplied grammar, that hint to the user what the grammar is expecting next by way of entry.

Up to now text editors for RISC OS have had a mish-mash of features for pattern-matching or syntax-colouring, usually tailored to BASIC or assembler. But none have had truly generic capabilities, where the grammar for the text is user-supplied. I think that is what we need for the future.

But none have had truly generic capabilities, where the grammar for the text is user-supplied. I think that is what we need for the future.

What would be really future-proof concerning support for a variety of programming languages is a good integration of the Language Server Protocol. One of Microsoft’s better ideas.

I’m an amateur who dabbles in BBC Basic and (old) VB and don’t contrib to the OS codebase, but am probabaly a fairly typical “non techie” end user who is attracted by the pi and is old enough (40) to have fond memories of Risc OS and have some degree of investment in it and familiarity with it.

I’d like to make some real/usable software for the platform but yeah, the lack of accessible and up to date information at the beginners level for moving on from text-mode BASIC to creating WIMP applications, and also modern integrated tools for that is a big hurdle. While the OS team definitely need a decent C IDE, it would be good if there was something akin to that for BASIC, even if it was just a modernisation of something like AppBASIC or Dr. WIMP along with some accessible documentation (I know there was some for Dr. Wimp at some point, but can’t find a way to get hold of it now.) – Something like the early versions of the VB envrionment would be amazing, but yeah, I’m also aware that something like that is prob way beyond the resources ROOL could bring to bear, and there’s a lot of other stuff that needs fixing/updating/creating to keep the OS rolling.

As far as Dr Wimp goes, there is some stuff available through PackMan, although it may be a bit out of date.

Although I have never used Dr Wimp in anger, I have made a few bug fixes and mods (as have at least two other frequenters of this forum), including to the documentation. The latest versions of the Dr Wimp should be available from the Archive (magazine) site. I am not sure offhand what the actual urls are, but I am sure Gavin can confirm. If all else fails I have copies of the latest versions.

There is certainly scope for improving Dr Wimp to bring it up to date. One area that stands out is that there is no support for the Toolbox, which would be very useful for Wimp programming.

Remember that the Dr Wimp library is a fairly low level library, but does achieve a lot – you only have to look at e.g. Calibre and Labella to see what the late Ray Favre managed to produce.

@Jasmine: If you are programming in BASIC, and need some debugging facilities, then you should look at my Reporter as it has some facilities specifically for BASIC – and all of the normal facilities can be used from many languages.

The latest versions of the Dr Wimp should be available from the Archive (magazine) site. I am not sure offhand what the actual urls are, but I am sure Gavin can confirm.

It was available through Ray’s site, which was supposedly under Archive’s protection. However, the Nominet registration expired on 26 November this year, and the site is now off the internet. The Wayback Machine appears to have failed to capture the site, too. :-(

If all else fails I have copies of the latest versions.

Likewise.

Perhaps it’s worth remembering that on other platforms, IDEs have been around for a very long time. I think the first was Turbo Pascal v. 3. In the 1980s. On CP/M. Later versions followed, after version 7 for DOS TP for Windows followed. Delphi 1 arrived about 1992; a 16-bit application, so it shouldn’t task RISC OS unduly if something similar to it was created.

In these days of high-DPI displays GUI designers aren’t as simple to use, as layout managers are needed. Given the right library, developing the GUI in code I can be easier — whether in an XML-based language like Microsoft’s XAML or in the programming language itself as in Apple’s SwiftUI or Google’s Flutter (which uses Dart).

Recently, I’ve been developing versions of the same application on different platforms. It’s an OCR application, using the Tesseract library, which displays the image being OCR’d side by side with the resultant text for proofreading purposes. I’ve developed a Windows version using WPF and C# with Visual Studio, a Mac version using Swift, and I’m currently starting on a Linux version using Qt/C++.

So far I’d say the Mac version has been the most difficult to do. The GUI designer in XCode isn’t intuitive, especially hooking up events, but the main problem was with the documentation. The Swift wrapper for Tesseract was easy to find and use, but it was simpler things, like setting the text content of the TextView (multi-line text editor component) that was the trickiest. Apple’s documentation is friendly enough, but isn’t the comprehensive reference it should be. There are very few books focusing on using Swift to develop Mac apps, and an additional issue is the project-based approach many books have — which isn’t helpful if none of the projects is close to what you want to do, Actually installing XCode, however, is straightforward provided you have the disk space (20Gb).

Windows was definitely easier, even though WPF isn’t as well covered as some of the other ways of producing a GUI. I found the object browser useful in exploring the C# wrapper for Tesseract. All the basic WPF libraries are comprehensively documented with useful examples and tutorials. VS also makes deployment simple. It was straightforward to scale the size of the image display — something I’ve yet to work out how to do on the Mac version.

The latest attempt uses Linux, Qt and C++. Specifically, Debian 10 (Buster) running within Chrome OS. It was tricky to find out what to install; there isn’t a convenient meta package to install everything. But an internet search quickly found the answers, The IDE — Qt creator — also needed some initial configuration. But when this was completed, I got a program working which displays an image that can be scaled up and down. The Tesseract part will have to wait a bit longer, but there is plenty of documentation available — the Qt documentation is excellent.

What lessons are there? Documentation is crucial. Documentation on developing GUI apps for RISC OS is sparse, apart from Steve Fryatt’s work. And I wouldn’t really want to write an app in C anyway. Tesseract version 4 and later need a fairly recent GCC, too — and version 3 is much l so effective. Away from C and BBC Basic, there isn’t much readily available. Good GUI creation libraries also help.

IDEs are important too — but perhaps we should create “Turbo Pascal” before "Delphi"…

The number of bits is not really relevant. The important part is the “integrated” in IDE, and in this respect, we are looking at an utter failure.

Basic features, in whatever language. The ability to run the code source line by source line, to examine and modify variables, to look at the calling stack (as function names, not gibberish addresses). And it would be nice to highlight on the fly where you may have made an error, or failing that take you directly to the relevant bit of code.

TurboC and TurboPascal did this sort of thing in DOS.
Delphi and VisualBasic did this fully multitasking.

We… Have a set of command line apps and a somewhat crashy debugger that only works for specially prepared C and assembler code.

There’s nothing for BASIC, and there’s nothing for module code. Though, while I greatly like the idea of being able to add lots of custom functions in the form of modules, it does not sit well with me that they run in SVC mode. Most of my stuff has no need to do such a thing…but I digress.

Debugging for me, usually, is writing in conditionals to spew stuff at DADebug to run the code, then read what happened. It’s basically the same sort of thing as I did on the BBC Micro (spitting characters at the VDU).

It’s okay, I guess, if you grew up doing such a thing. But compared to everywhere else, it’s like a trip to the Dark Ages.

I feel that such integration is what’s necessary, and what’s going to be the really hard bit.

Perhaps something akin to Aemulor or ADFFS which can present a highly sanitised version of RISC OS with the ability to arbitrarily stop and examine the machine state? Because a debugger isn’t a whole lot of use if it goes arse over cupcake and has a fifty-fifty chance of taking the rest of the machine with it. DDT, I’m looking at you!

As for saying how good things are elsewhere, well…

Linux Foundation, revenues of ~$177M
Microsoft, revenue $51.7B
Apple, revenue $378.35B
Figures are revenue, not profit, for the fiscal year 2021.

And in our corner of the world? How many actual employees does ROOL and ROD have? I mean, for themselves, not just people like Andrew wearing a different hat.

There lies the problem. The great gaping chasm between “that which would be nice” and “that which is possible”.

Starting with TP would be nice, but how much work would be needed to even get that far?

I can recall IDEFS on RISC OS quite early on.