Programming IDE for RISC OS (CodeCube Cloverleaf project)

I think there is a necessity for a comprehensive programming IDE for RISC OS.
What currently exist for C is only a collection of programs that you can use.
This makes it quiet difficult for programming newcomers to RISC OS to get started.

For BASIC there exists AppBASIC which is a well designed IDE if you want to program in BASIC.
Sadly the programmer is not available anymore as his health is not well.
So AppBASIC might be lost if future updates are needed.
AppBASIC website

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

A really good base for an IDE would make !sourcery from A-really-small-software-company by Richard Windley.
Richard Windley.
!Sourcery website

Sadly he doesn’t answer to his contact form or his email. Does anyone have a direct contact to Richard Windley? (I have his gmail address)
I would prefer to license !Sourcery’s code to get results as fast as possible.

We would first base the IDE on GCC as the DDE is not free available. But it should be possible to integrate the DDE at a later stage wihout a big effort.
Also I would like to offer support for other languages as Python, BASIC etc.
I had a short chat with Chris Johns (the RISC OS porter of Python) and he thinks that it can be possible to integrate Python into an IDE.
But that would be done only after it is done for GCC.

As editor I would try to integrate StrongED in a modified form to make it more compatible to modern text editors.
But with a “StrongED Classic” handling as option so that old StrongEd users don’t need to adopt to the new version.

One big issue is also debugging in RISC OS and I would like here to use the new UCDebug which supports ELF files that are produced by GCC.
Github UCDebug

Here is a short incomplete list of features of the IDE

Functions of CodeCube
*Create project
*App name
*App logo
*App programming language (C, C++, Python, BASIC, Assembler, Fortran, Pascal)
*Folders inside app
*Folders inside $.boot.choices directory
Manage windows
Manage menues
Manage icons
Manage included files
Editor (based on StrongEd)
Run / compile program
Debugger (using any existing debugger)

Any comments and suggestions are welcome.

Sounds great. I’m currently dabbling in C with OSLib and the ToolBox. I found the lack of a working Vi editor an initial hurdle, settled on Zap (emacs keymap), utilising the TaskWindow and Make-files. As a reference, I’m using “Learn C the hard way”, the Toolbox manual, and I’ve used James Hobson’s videos.

Both StrongED and Zap could be better with “out of the box” GCC compatibility. The ToolBox manual is probably great for WIMP experts but not a new starter; it’s hard to find what you need.

I guess there are various approaches:
1. C Beginner – make use of the tools available, GCC, Make, TaskWindow, OSLib, ToolBox, FileUtils, Zap or StrongEd, Diderot and StrongHelp. These work with Learn C the Hardway, etc. Sourcery, Git perhaps later on.
2. Enhance StrongED, Zap to provide IDE facilities, GCC interaction, incorporate Diderot and Sourcery, Git.
3. Take an OpenSource project such as KDevelop, Vim and update them to work with RISC OS. I’d recommend this approach to present newcomers and new starters with an interface they might be familiar with.

I think what we really need (and thus, impractically unfeasible) is something akin to Visual Basic where the IDE is a complete self contained development system with editor, window designer, menu designer, debugger, etc all within.

But not just that, how VB worked was by allowing you to write code for specific “events” (program starting, clicked on this icon, etc etc). All of the underlying grunt work was handled by the environment. I didn’t have to start up the program, load resources, open templates, load each window, define the menus… all that was done automatically. As such, I’ve written several programs for Windows quite quickly, quite simply, and with no idea of the underlying mechanisms of the system.

We need something like that. Something where you can attach code to things (like this function runs if I click this icon in this window) with all the boilerplate hidden.

Another good thing that VB offered was methods applying to the icons. There was a set of functions, but for doing something like setting the text of an icon, it was something like MyIcon.Text = "blah blah", no need to work out what the correct function would be, you just do that and the underlying system makes it happen.

With something like that, programming on RISC OS will be easy and pleasant and ought to attract some people.

Attaching plasters and chewing gum to existing tools is more a crutch. The problem is that we have editors, libraries, and languages that are simple by today’s standards. We’re used to them because we grew up with them, but to others it might seem all a bit Dark Ages…

Anything that makes programming easier for RISC OS is to be welcomed. That said, I am not sure that the IDE idea (one all-singing all-dancing application) fits very well with the idea behind RISC OS (lots of small interworking tools). RISC OS emphasizes the GUI and plays down the use of the keyboard. In my unsteady first steps with Linux I found myself missing StrongED, Zap and even Edit. Where in the Linux world can you find an editor where you can drag and drop selections of text between windows? Or drag a script (Awk, Python, Lua, …) into a window of text to modify that text without recourse to the keyboard? Yes, I know that I am coming at this with a very different perspective – anything that involves use of the keyboard apart from editing text or naming a file seems like a clumsiness. Very few window managers for Linux offer the user any facility for exploiting drags of objects across the screen. It is easy to understand why; in a multi-user system, Alice’s tasks have no right to know what Bob’s are doing. RISC OS has the advantage of a single window-manager. Many IDEs are partly there to offset the graphical disadvantages of a multi-user system. That is why so many Linux applications seem to be recreating the filer for themselves, with inconsistent graphics if they are using different graphics libraries.

There have been application-generators for RISC OS since the beginning. Their purpose is to shield the user from knowing about Obeyfiles, and AppBasic is a good example. However, I am not sure that they are doing any favours for newcomers to RISC OS programming. At some point you need to understand system-variables and Obeyfiles; though I grant that the absolute beginner might be happier to avoid them.

I am probably too well known for banging the drum for Lua, particularly as a good language for beginners. Like BASIC or Python you can write a program with a text-editor, save it to a file, set its filetype to Lua, and click on it to run it. I think Lua is rather simpler than Python; by design it is not batteries included . Lua has powerful debugging facilities, which have not received the attention they deserve.

It may be that I have not done Lua justice in my attempts to promote it as a useful language for RISC OS. Perhaps I have put people off? Anyway, I claim that is a whole lot easier than C or BASIC, and that there are some jobs, data-extraction for example, for which it is particularly suited.

Before I retired, I used the Microsoft IDE a lot. The built-in editor is a two-edged sword: the tabbing makes it possible to swap quick looks into multiple files, but also restricts the view on the main file being worked on because it only occupies a part of the IDE’s window, and, let’s face it, screens are never big enough to see the part(s) of the file you’re working on with enough context.

So it must always be possible for the editor to escape the IDE’s confines and occupy as much of the screen as the user wishes.

Context-sensitive lists of auto-complete options are handy, but I’m not convinced that they speed up coding much. Too much time is taken swapping between typing and selecting. They tend to cancel out.

I think the main things I miss on RISC OS are:

• A debugger for GCC code. I’ve been wondering if the GDBServer in the RISC OS GCCSDK tree could be made to work (but you need two computers or a RISC OS running under emulation on the same computer to make it useful).
• Go to the definition or declaration of a function by selecting it and pressing a key.
• I do like the context sensitive list of auto-complete options, these usually prompt you with the most likely item so it’s a single key press to insert the correct value.
• Hovering help on what the parameters are for a function as you type it in.
• Modern IDEs can even highlight dodgy code as you write it so you can fix it before compiling.

I don’t have a preference for if it’s a single IDE or multiple applications. StrongED always seems a pretty good editor, so maybe some sort of plugin that could give StrongED a project wide look at the source files so it knows where to search for things might be possible.

fits very well with the idea behind RISC OS (lots of small interworking tools).

I’m not looking at what RISC OS does, I’m looking at what can be found elsewhere.

can you find an editor where you can drag and drop selections of text between windows?

I’m my limited experience, RISC OS is one of the few systems to have made any sort of useful drag and drop.
In those other systems, ^C then ^V. ;-)

RISC OS emphasizes the GUI and plays down the use of the keyboard.

Swings and roundabouts. I would actually prefer the Windows setup (as of XP) if it was consistent. If you’re using both hands on the keyboard, it’s a mental and physical break to leave the keyboard and reach for the mouse to do something simple.

To give an example, I’m quite used to the RISC OS drag-select way of selecting text in an editor, but I can’t help but think that holding Shift and using the cursors (and Page Up/Down plus Ctrl) isn’t a more flexible way to select text.
I reckon if I have two words back to front, or if I want to move the current paragraph to after the following one, I could probably do it quicker with keyboard than with the mouse. (and it’s worth noting that under Windows (etc) you can also use the mouse)

anything that involves use of the keyboard apart from editing text or naming a file seems like a clumsiness.

You’re picking specific cases like dragging files around. How about taking a document edited in, say, Notepad++ and pasting it into a website?

^A ^C
Alt-Tab
^V

The first selects the document and then copies it to the clipboard.
Then switch to the browser app (we’ll assume it’s already set up, like the editor was).
Then paste.

It’s how I update my blog on Windows and Android. Maybe 2-3 seconds tops.

On RISC OS, press F3 to call up the save dialogue, then drag the icon into the browser. It’s how I update my blog on RISC OS. It takes 2-3 seconds to make the shift from keyboard to mouse and locate the pointer…

Having to leave the keyboard (and interrupt flow) is a clumsiness.

Alice’s tasks have no right to know what Bob’s are doing.

I don’t get this comparison. The GUI is a viewport to a virtual workspace of the currently logged in user. When it is showing Alice’s tasks, Bob’s shouldn’t appear. The only time they should be seen to exist is if Alice has admin rights…or logs in as Bob.

That is why so many Linux applications seem to be recreating the filer for themselves

Frankly, it’s because the filesystem access and drag-drop is shit. The system will provide a generic “save as” box, but the moment you want to add something specific to the program, you basically have to create your own custom dialogue. I have numerous programs on my PC that do this.

The problem is that these systems have poor/lousy/pathologically broken drag and drop, so the way to access the filesystem is for every app to have its own “portal” into the filesystem.
It’s horrible when you want to save a file from one program and load it in another (if you can’t copy paste) because they will probably start up with different default directories.
Then, how about loading a file, modifying it, saving it elsewhere. Repeat, and realise quickly how utterly backwards such a setup is.

There have been application-generators for RISC OS since the beginning.

Yes, I’ve written one (unfinished) called Seashell (sorry…).

Their purpose is to shield the user from knowing about Obeyfiles,

Therein lies the problem. The generator should shield the user from the nuts and bolts of the language.

You shouldn’t need to know how a polling loop works until you start to want to do some more advanced stuff. You shouldn’t need to know how to bring up an application and load its resources. The problem with coding on RISC OS is that jumping through all the boilerplate is something we have to look at every time we create an application.

I think the Toolbox was a start at making something more higher level.

It may be that I have not done Lua justice

You have posted some nice little snippets along the way, but I’ll be honest – it looks like random letters and punctuation abuse. I’ve not had the time or brainpower to learn any Lua, so this (found by a quick search) will make sense to you. I don’t even know how to begin parsing it:

(getmetatable "").__mod = \ (s, t) => s:gsub ("%$([%w_]+)", t) end

Maybe it’s a little too concise? ;-)

A debugger for GCC code.

I’d say “a debugger” period. You’ll know I’m not a fan of DDT as it’s rather crashy and a real PITA to use. Plus it seems that if you ^C to run a program at full speed until it crashes, it’ll stop and report the crash, but it won’t tell you how you got to that point.
Accordingly, DDT is my debug of last resort.

I do like the context sensitive list of auto-complete options, these usually prompt you with the most likely item so it’s a single key press to insert the correct value.

Yes. If it’s a library you don’t use often, or a library that is utter gibberish (like RISC_OSLib), it can be extremely useful to have a prompt for structure elements. It’s either that or rummage around in header files or hope a StrongHelp file exists.

Hovering help on what the parameters are for a function as you type it in.

Yes, you see, it’s little things like that which can make a difference.

What advantage is there in a monolithic slow memory hog IDE versus the way we do things already more effeciently using multiple programs together,

Because there’s a lot of boring grunt work in getting all the bits talking to each other, and even then it is incomplete (as noted above, pop up prompting of function parameters, structure elements, etc). Little things that make a programmer’s life easier.

more easily than done in most modern IDE environments?

There is value in having things integrated. When writing code for the ESP32, I selected what my board was from the UI, picked additional libraries from the UI, then wrote the code in the editor.
Finally, I prodded the upload button.
It compiled (excruciating slowly), linked in the correct bits and pieces, communicated with the ESP device, and flashed the new firmware.
By itself.

I did need to fiddle around with pytool and Python on the command line, but that’s because I am still using XP. It was a one-off, from that point on it’s all done through the UI.

I give this as an example because around these parts you need to call the compiler and the linker yourself (command line or Obey file) or figure out how to write a MakeFile. Zap/StrongEd will invoke the MakeFile with Sh^C to build the project. Anything else will need more MakeFile magic or more steps.

Steve (Fryatt?) has his builds create a ready to upload zip file. I like that idea, but I’ve not sussed Makefiles enough to add such a thing.

Are you starting to see the difference between RISC OS and elsewhere? Sure, it’s a lot more powerful the way we do it (one could wonder if Steve’s archive method could be expanded to call wget with a PUT request to directly upload the archive?) but on the other hand it is a lot more fiddling around, and is a lot of work for the typical uncomplicated use case. It’s not particularly friendly.

Instead just do an editor that has better code folding

Hmm, I’ve never used folding in an editor. To my mind, such a thing is an open admission that it doesn’t properly support chapters or sections (text document) or the ability to jump to functions (code).
Try Sh^H in Zap. List of functions. Easy to pick one and go right to it. No folding required.

So long as the editor supports Throwback you have everything a modern IDE provides, though way easier to use,

Haha hahahahahahaha.

Okay, wait, you’re being serious.

Try interactive in-editor debugging and code tracing. Not in a stand alone program, directly in the editor/environment. VB5 could do this 24 years ago.

Another thing to consider is that children’s first experiences with “programming” may well be dragging and dropping named pieces of program together like this:

If you’re about the same age as me, you probably learned BASIC.

There’s nothing wrong with BASIC (and Edsger Dijkstra can go swivel), but if people are expecting something easy and friendly and they have to contend with what we use…they may decide to just not.

I mean DADebug and spewing stuff to vdu are how I do most of my debugging. Not so very different to how I did it on the BBC Micro. There ought to be something wrong with that, you know… ;-)

Well, quite, Rick!

I used to use VB6 extensively, and it was miles ahead of anything on RISC OS. The step-through debugging, variable editing and manipulating the program counter, it is easy-peasy to debug.

VB6 also included tooltips with comprehensive function prototypes and links to documentation. And the discovering of APIs was super-simple with intelli-sense.

And this was all over 20 years ago. There is a bit of catching up to do!

This looked interesting, but I have not yet given it a go.
https://jeanmichelb.riscos.fr/Dev.html

I would quite like auto-complete and pop-up help in StrongEd. And a tabbed view, where I can easily snap tabs between different windows and split a window for side-by-side coloured diffs.

Oh, and to step through the C source whilst it is running, breakpoints etc.

No-one seems to have mentioned source control yet… We need it, badly, with support for at least Git and SVN, and possibly CVS for the masochists. It would also need to handle filetypes in the same way that they’re handled if the sources are edited over on Linux under the GCCSDK (so the usual trick of ,xxx filename suffixes).

With that comes the desirability of being able to store BASIC programs as text in the source control system, to enable it to do what it needs to do.

Context-sensitive lists of auto-complete options are handy, but I’m not convinced that they speed up coding much.

Having VSC look up the parameters for (or even the exact names of) the functions that I need to call is incredibly useful. It’s almost removed the need for documentation.

Steve (Fryatt?) has his builds create a ready to upload zip file.

Yes, that’s me… they also spit out RiscPkg-ready packages, these days, too. It takes a lot of the hassle out of releases and test builds, which is an incentive to actually do releases.

:)

[For those who are interested, the files can be found here. They’re for use on Linux, within the GCCSDK, though — see my description of my build environment for what that looks like.]

Most toolbox projects I see are either way more code than they would be if not using the toolbox, or they include huge libraries, including those in C++ that include huge outradgous libraries of extra code to work. Either way they use way more code than talking strait to the WIMP.

The ones that I’ve seen just call the Toolbox SWIs.

We have the best possible kind of debugger built into the OS. As I would want to debug the running code, not the debug statements or the high level code it is compiled from.

Most people would prefer to step through the code that they’ve written in the first instance, seeing the contents of structures, the values of variables and watching execution stepping in and out of loops, if statements and functions.

ARM code level debugging is what one does when one has found a compiler bug, or when there isn’t a modern debugger available.

I prey you are wrong. In my school as a young kid it was a structured language modeled after BASIC that was the first beginnings for 7 year old programmers that were poor enough not to already be learning at home.

Our age group was either past primary/secondary education by the time home computers were common so learning structured languages and “normal” coding was probably a leisure time activity or a tertiary education thing.

Ricks pretty picture sums up modern education – no real knowledge of the nuts and bolts.
Not always a bad thing, but it does introduce limitations

Big thing with the built in BASIC – is that does thing right away – and you can use Progs like Druck’s version of Task window for multi tasking.

There is a Prog for modifying BASIC so you step through the code – seeing selected variables as you go (26bit at the moment)

Big problems comes with Modules ie testing/debugging.

AndyS has a magic version of RPCemu that spits out Function names as RO/Prog is running.

Thanks for the valuable feedback all!

@Andrew McCarthy
Yes I forgot to write that the IDE should be based on Toolbox. And if needed we will probably extend Toolbox and the TBX library.
Also we have used the TBX library in !ChatCube for automated redraw of the window content.
The !CodeCube IDE should make it easier to handly any WIMP events.
Each element should have a list of WIMP events that it can or should react to with each of this events is connected to a function.

I will check out the other libraries and IDE programs. I know also Lazarus as IDE which is the open source successor of
Borland Delphi which was very famous 30 years ago.

@RickMurray
Yes the clipboard support in RISC OS must be improved significantly. So that is on the to-do-list.
Any RISC OS program should support clipboard functions.

I think what we really need (and thus, impractically unfeasible) is something akin to
Visual Basic where the IDE is a complete self contained development system with
editor, window designer, menu designer, debugger, etc all within.

This is exactly what I want to do with the IDE.

But not just that, how VB worked was by allowing you to write code for specific
“events” (program starting, clicked on this icon, etc etc)

Yes that would be my prefered solution also for the CodeCube IDE. (similar Delphi and as you describe VisualBasic)

Another good thing that VB offered was methods applying to the icons. There was a
set of functions, but for doing something like setting the text of an icon, it was
something like MyIcon.Text = “blah blah”, no need to work out what the correct
function would be, you just do that and the underlying system makes it happen.

Yes is excactly how Delphi also worked. For each element there is a set of variables and events that can be accessed easily.
That is what I want to have also.

Attaching plasters and chewing gum to existing tools is more a crutch.

Yes that is the problem in RISC OS that many things are a patchwork or tools and fixes.
This is also part my Cloverleaf project to clean up the „mess“ and make it an integrated complete solution again.

I’m not looking at what RISC OS does, I’m looking at what can be found elsewhere.

That is what I am saying. Looks at the best of all OSs and include them into RISC OS if it doesn‘t oppose what represents RISC OS.

I’m my limited experience, RISC OS is one of the few systems to have made any sort of useful drag and drop.
In those other systems, ^C then ^V. ;-)

Yes as I said before the RISC OS clipboard must be brought up to the standards of other OS. Maybe we can make an even better one? Maybe a clipboard that hold all previous copy actions. And keypress (eg Cltr-Y) to add more text to the current copied. A clipboard window that shows you all copied media and select the one you want.

The problem is that these systems have poor/lousy/pathologically broken drag and drop, so the way to access the filesystem is for every app to have its own “portal” into the filesystem.

That is one of the many reasons Linux is no alternative for me to RISC OS. Some Linux filers have even no option to change the file type and you must do it in command line mode….what year is this? 2021 or 1985?

@GavinWraith
The !CodeCube IDE will be aimed primarily to write WIMP applications.
But it still should be possible also to write low-level drivers with it. We don‘t want to cut down RISC OS to become
another Linux or Windows copy. But we also look into any other OS if they have improvements we can integrate into RISC OS
without betraying the philosophie of RISC OS.
I have personally have not seen anything good in Linux other than that there is a huge number of programs.
But open source means also less service.

About Lua: Well maybe Lua can be also one of the program languages supported by !CodeCube.
It is always the question how many users are there. Marketing is needed for Lua then.
The best way to do that is making Youtube vidoes with detailed tutorials how to use it and what the language offers.

@Dave Higton Noted!

@Alan Buckley

A debugger for GCC code.

The UCDebug should solve that. Although it was designed for teaching purposes at the moment so we might need to add some features.

Go to the definition or declaration of a function by selecting it and pressing a key.
I do like the context sensitive list of auto-complete options, these usually prompt you with the most likely item so it’s a single key press to insert the correct value.
Hovering help on what the parameters are for a function as you type it in.
Modern IDEs can even highlight dodgy code as you write it so you can fix it before compiling.

This functions can be added.
The „hover“ function is one of the features that aren‘t base functions of RISC OS. This should be included in the future.

StrongED always seems a pretty good editor, so maybe some sort of plugin that could give StrongED a project wide look at the source files so it knows where to search for things might be possible.

Yes an overview of all files included in the project/program is one part missing in !StrongEd as it is „just“ a text editor and not an IDE. Also the menu structure needs to be modernized as many option look very „80th-ish“.

@DavidS

What advantage is there in a monolithic slow memory hog IDE versus the way we do things already more effeciently using multiple programs together, more easily than done in most modern IDE environments?

An IDE provides a „One-stop“ solution of programmers. Install it and start use it.
Currently new RISC OS programmers need to investigate weeks what programs and libraries they need to use to achieve anything. It takes another 2 to 6 months before they understand all the underlying RISC OS features regarding WIMP and cooperative multi-tasking.

We have the best possible kind of debugger built into the OS. As I would want to debug the running code, not the debug statements or the high level code it is compiled from.

Hahaha! I am not laughting about you but what you say sounds funny as you are the first programmer that says that they are happy about the debugger environment in RISC OS. Well if you are happy then I am happy too!

Write a better text editor instead. One that supports better code folding.

I would like feedback from you or more infos about codefolding when the IDE is running already.
As we want to offer the best user experience that is competative to other OSs.

About BASIC:
For me BASIC is good language to start learn about programming. To learn programming you must learn about variables, data types, conditionals branches, functions, procedures and loops. After that you can start explore the OS.
I am actually no fan of C as it is powerful but complicates things also many times.

@Richard Walker

And this was all over 20 years ago. There is a bit of catching up to do!

That is exactly what we need to do!

@Steve Fryatt

No-one seems to have mentioned source control yet.

Is source control part of an IDE?

Is source control part of an IDE?

In many modern IDEs, yes. Most modern IDEs, in my experience, are also organised around a plugin-structure, so that the user can add functionality for the program language they are currently working on. There are (several) open standards for things like syntax-highlighting and other editor configurations that you could implement if you want to go this route. The alternative, again in my experience, is IDEs geared toward a single programming language and (attempting, with mixed results) doing it well for that use case.

A debugger for GCC code.

The UCDebug should solve that.

Last time I spoke to them, it was only going to be an assembler debugger and they had no plans to support GCC. Has this changed?

For me BASIC is good language to start learn about programming.

;) Basic Meh, so cliched! For new starters, I’d argue that Python should be the focus. C, C++, Lua, Perl and of course Basic should be a supported language, along with other languages that have compiler support. Let people decide which language they want to use. :)

Libraries relating to C and C++ .., TBX, OSLib and SharedClib.

As we know, the audience for CodeCube might expect different things. A complete beginner, a new user, just an IDE. A beginner familiar with RISC OS, then there’s the Linux or Windows users each will have expectations of an IDE, especially around keyboard shortcuts. Would a Vi, EMACS, Visual Studio and Atom user be able to utilise the IDE without thinking too much about it?

Another IDE perspective to consider. Would picking up a book on Coding, then trying to use RISC OS be made easy or a chore? How can that be addressed? BTW I am grateful to those that work on the GCC toolset and associated tools that includes PackMan, FileUtils, Zap and Cppcheck. These tools together have enabled me to use a beginners book on C (LCTHW) without too much effort.

Incorporating some other debugging tools GDB, Valgrind and Cppcheck (already available on RISC OS) might be useful.

An IDE that could debug code in a virtual environment would be a great asset, especially one with access to the GPIO pins of an RPi.

but I’ll be honest – it looks like random letters and punctuation abuse.

You are quite right Rick. It is too concise. My problem is that I come across something that I think is neat, and then I blurt it out without sufficient thought for explaining it properly or the impression it may make. In this case (close your eyes now if you are not ready for it :) what

(getmetatable "").__mod = \ (s, t) => s:gsub ("%$([%a%w_]+)", t) end

I have always liked StrongED’s configurability. I have just fired off an email to Fred enquiring whether there is any way of colouring a section of text. IDEs should be able to describe parse-trees. I quite like the way TechWriter can display the structure of a document, using coloured lines down the left hand side; this is a good solution to the problem of identifying nested structures. The trouble is that writing mode files for StrongED has become something of a black art that only a few know.

I quite like the way TechWriter can display the structure of a document, using coloured lines down the left hand side; this is a good solution to the problem of identifying nested structures.

I’d love to have that in StrongED’s BASIC mode. It exists in notepad++ in Windows, and is invaluable when writing PHP.

@Stefan Fröhling

So AppBASIC might be lost if future updates are needed.

Something could be written that implements the same features (I did a fair bit of that for AppLua). The main problem is the extensive help system that Joe created, which is one of AppBasic’s greatest assets.

@Andrew McCarthy

Both StrongED and Zap could be better with “out of the box” GCC compatibility.

Could you elaborate on that? I’m sure StrongED’s GCC support could be improved, provided I know what to aim for.

The ToolBox manual is probably great for WIMP experts but not a new starter; it’s hard to find what you need.

Sorry but I have to disagree with that. Using AppBasic as an example, setting the text for an action button is done by:

PROCActionButton_SetText(object,component,Text)

Which is way easier than using the Wimp directly; find the button’s text buffer, write a string to it then call Wimp_SetIconState to force a redraw.

@Alan Buckley

Go to the definition or declaration of a function by selecting it and pressing a key.

In StrongED, place the cursor in the name and press c-G (twice if definition is in a different text).

so maybe some sort of plugin that could give StrongED a project wide look at the source files so it knows where to search for things might be possible.

The idea behind StrongED is that all source are loaded into it, hidden (cs-H) and accessed through the List-of-Windows window (c-L). Searching for things is then done in memory (c-F or F2).

That’s why there is no directory search built in. I did create an add-on to search in the directory of the current file (c-F11, requires Lua).

Just to be clear, I’m only explaining why it currently works the way it does. I’m not saying it couldn’t or shouldn’t be changed.

@DavidS

Instead just do an editor that has better code folding,

In what way should folding in StrongED – currently the only RISC OS editor that supports folding) – be improved?

@Stefan Fröhling

Also the menu structure needs to be modernized as many option look very „80th-ish“.

What menu structure would you propose for StrongED?

Changing the menu structure is a significant piece of work as the structure is reflected in the code. So changing the menu means changing the code.

@Gavin Wraith

TechWriter can display the structure of a document, using coloured lines down the left hand side;

I don’t have TechWriter so could you load a file, say a Lua script, into StrongED. Configure it to use an outline font and set the size really small, say 3pt. Is that similar to what TechWriter does?

The trouble is that writing mode files for StrongED has become something of a black art that only a few know.

Writing mode files hasn’t really changed over the years. What has changes is the number of mode authors, there are very few left. These days almost all modes are maintained by me.

TechWriter can display the structure of a document, using coloured lines down the left hand side

That sounds like the way Notepad++ does it, as below:
http://www.adamshome.org.uk/RiscOS/Notepad-functions.jpg

In the PHP case shown, when the cursor is after the opening bracket of a structure the red line is drawn to the closing bracket. The edge marker also shows the same extent.

If a closing bracket is missing, the edge marker goes to the end of the document.

@Fred Graute
My observation was about ToolBox’s manual, not WIMP programming versus Toolbox usage. I’d undoubtedly point any beginner at the ToolBox.

StrongEd and GCC. I create the directories needed and the required subfolders; c and potentially h and o. I write some code and make a Makefile. What do I do next? Click on the Run icon; click on the MakeFile icon? From memory, I gave up because I couldn’t work out how to configure StrongEd’s TaskWindow with enough memory for the compiler to run; you’ve since helped me out with that :)

Most toolbox projects I see are either way more code than they would be if not using the toolbox

Please name a few examples.

Then we can compile a list of “source code you should NOT look at when learning how to use the Toolbox”. If used right, the Toolbox can save an awful amount of code. Only for complex UIs you sometimes need to fall back to plain WIMP, and then it is just “as much code as using plain WIMP”, because that’s what you are doing.

What advantage is there in a monolithic slow memory hog IDE versus the way we do things already more effeciently using multiple programs together, more easily than done in most modern IDE environments?

I am constantly switching between developing on RISC OS and developing on Windows. I can certainly say that using a powerful IDE (on powerful hardware, so I don’t care much about the amount of memory used, and it feels really quick for most operations) makes development at least an order of magnitude faster, less error-prone, more efficient.

The IDE understands the code. It can auto-format the code, so it is easy to follow a style guide. It integrates the VCS of choice (in my case, CVS and SVN and Mercurial and Git) into a unified UI so I don’t have to remember arcane command line details for every VCS. I can easily access the version history of any file or the whole repository, explore the branches, make diffs between revisions (and, because it understands the code structure, can show them in a logical way instead of a simple line-based diff), find out what has been changed and when. The IDE provides a powerful source-level debugger which makes it easy to follow your code executing with full insight into fields and objects, being able to change values and even code to try out changes while keeping the code running. Because the IDE understands the code, it can provide refactoring tools that go way beyond anything possible on a search-replace basis. Auto-completion based on semantic information like availability and accessibility. Quick-fixes for common errors. Showing syntax errors without the need to compile. Showing warnings for typical bug patterns spotted by sophisticated bug detection tools with configurable rules. Showing API documentation wherever I need it, nicely integrated inside the editor. Giving high-level structural information on every abstraction level. This allows for quick navigation around any parts of the code, no matter how complex the project is. Or even a large amount of projects at the same time (the currently open workspace of my IDE has 28 projects open and accessible at the same time, each consisting of tens to hundreds of files).

So…most of the things I wrote about above do not even begin to exist on RISC OS, so it is surely not more efficient and not easier. And if these features/tools were available, I could not imagine using twenty seperate tools for those jobs without good integration. Integration – that is what IDEs are all about.

Instead just do an editor that has better code folding, and maybe even function definition referencing. Or an extension for one of our current editors.

A good start would be an implementation of a LSP client for StrongED. Perhaps 1% of the way to a full IDE. Or to an Emacs clone, the favourite IDE of the bearded Unix devs (or was it vi?) :-)

@DavidS,

As a low life non-coding user of RISC OS I note that you are the only one in this thread
who does not think that a modern type IDE is a good thing.

Well as a user of software written by the majority of this threads various contributors I
think I know which view I support.

As an aside, before making sweeping statements it would be a good idea to check your facts first.

Regards Ron.

Even if you write little code it does not matter, as any user has a valid point of view.

…and exactly here you are completely wrong when it comes to the topic discussed here. Here we have to listen to people who wrote or want to write major apps for RISC OS or on other system. I myself would never need a full blown IDE as I mostly write only my small ARM assembler intro/demo stuff and I’m happy with a text editor and some disassembler so I would never argue discussing here. What was your recent application developement…?