Programming IDE for RISC OS (CodeCube Cloverleaf project)

There was BasDT by Dick Alstein

Apart from any other 32-bit hiccups, it patches the BASIC module, which leads to it own problems, as Colin found. My own programming has been blighted by adopting ExtBASICAss, which also patched only particular versions of BASIC, however good it was otherwise. ;-(

I made a mokeup of the possible IDE interface.
Each window and element can be changed by the object inspector. By this inspector also all WIMP events can be accessed and defined how the elements react on events. The IDe could also offer eay access to databases, calender, media player, OpenGL/Mesa

Hello,
It is good to see that the debate on an IDE is revived.
I only work with RiscOs and I really appreciate it.
DDE is a good tool, I think GCC too, I mostly use the former.
When I was working I am retired now I used Borland IDE which offers a lot
of facilities.
I tried to build myself an environment to develop on RISCOS.
Current situation:
• The first tool is the ToolBox, equivalent to the Borland VCL, almost is
what I would like … I’m waiting for the " ToolBox Reunification " …
• StrongEd works very well and already allows good use of C / C ++ / h
files etc. Viewing functions and getting help with! StrongHelp are very
helpful, in addition to all the functions of an editor :-)
• The development directory structure is a DDE standard which corresponds
to the RISCOS Style guide.
• It is true as said above that there are many separate applications/Tools
to be able to use it.
• There are also a lot of obey or task-obey files to automate development.

I often reuse existing code and found myself with lots of windows per
application.
So I wanted to collect all the directories and their files in a single
window with buttons to launch the obey files.
I used Rick Griffin’s app and his excellent Treeview module. I can select
each file to open and edit it in StrongEd.
Please note this is not a filer, the management of files is entirely done
in the directory of files.
With the buttons you can, if you use the DDE structure for the development
directory, with a single click, compile, clean the compilation, install the
application and launch it. We have direct access to the Res file opened in
ResEdit. ResEdit’s essential companion comp(onent) button lets you name the various objects created with the ToolBox.
The OFiler button allows you to open the original workbook if necessary.

Stefan , your mokeup looks like what I built, which shows me I was on the
right track:-)
“By this inspector also all WIMP events can be accessed and defined how
the elements react on events.”

There are apps that work great to get this information: !WimpInfo,
!MouseInfo !WimpMon, the !XXXstat serie…..
in addition to those supplied with the DDE.

Thanks to Richard Walker:

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

For those who are interested, I can provide the source written in C / C ++
with the DDE.
Note: As many projects on other OS IDE work with XML files, I also have a
tool (prototype) to view them.

[xmltool]https://jeanmichelb.riscos.fr/XML.html

Sorry, I tend not to finish my programs when they do what I asked them to.
For a project like Stephan’s, it would be good to have specifications so
that everyone is interested.
It’s just my opinion.

ResEdit’s essential companion comp(onent) button lets you name the various objects created with the ToolBox.

I was interested in this, but I do not understand what it is. Could you explain more, please?

Diderot looks pretty useful and I am going to explore how it might be helpful with my BASIC programming. I just use the filer and it does not make any real problems for me.

Edit: And StrongED’s ListOfWindows.

Maybe Fred could be persuaded to make the LoW act like a tree, or he will come here and tell me it already can. ;-)

@Andrew McCarthy

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

Thanks, I see that now. Glad we agree on the Toolbox being better for beginners. :-)

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?

Ah, yes, the C mode could do with a revamp. The Run icon seems to be set up for single file C programs (using GCC). The Makefile icon is more generic as it just run a project’s Make file. I’ll have a look and see what I can come up with.

@Gavin Wraith

Fred Graute made a brave start with a project that he named AppLua based on the premise that because Lua resembles BASIC in its iterative and conditional structures ( while, for, repeat, if – then – else, ..) it should be feasible to try a straight translation from BASIC to Lua. I hope I am not misrepresenting him in saying this.

Not so much a premise but more of a desire. One of the main reason for creating AppLua was so that I could use it for Transient. When support for TrapDelete was added, Transient needed to keep track of where deleted objects came from so that they could be restored to that location.

Although I did manage to do that in BASIC using memory blocks and indirection it’s a rather uneasy fit. Lua’s tables (or Python’s dictionaries) seemed a much better fit for the job. Transient is written in AppBasic but there was no AppBasic-esque environment for Lua, so I decide to have a go.

By staying as close as possible to AppBasic I was hoping to keep the effort of moving Transient over to AppLua down. As well as creating a tool that was an easy next step for AppBasic programmers that needed a more versatile language.

In Lua definitions of values must precede their use.

This does pose a restriction, programs can’t be written as freely as they can in BASIC. Whether this can be overcome I don’t know, AppLua has been on the back burner for some time now.

@Stefan Fröhling

I think most of the display options are heavily related to Assembler or binary manipulations which are not necessary for a modern IDE.

There are no options for assembler in global or mode choices, only Dump mode has options for that.

I have one issue with the menu structure configuring for example the display font used. There is no info in the documenation how to achieve it.

The display font can be changed in the mode options. These can be reached by clicking Adjust (right mouse button) on the ‘tick’ icon on the toolbar (top of window). Or by Menu over a StrongED window, then last menu item > Open choices.

The global font options can be accessed by Select (left mouse button) click on the ‘tick’ toolbar icon. These options are also available from the iconbar menu.

In the manual this can be found under: Introduction > Configuring StrongED. There is also support for Interactive help which is the usual way to explore applications under RISC OS.

After asking around Micheal Grundlitz informed me that it can be done over the menu shown when click menu on the bottom bar.

Yes, it can, although I don’t think that I’ve ever done it that way.

Maybe you can improve key features of StrongED that benefits also the original StrongED and we do the integration into the IDE.

Adding support for the IDE is fine so long as StrongED can remain a single application. It’s just a hobby and I don’t want to maintain 2 versions.

The UI should initiate actions by the program by procedures/functions or is StrongED written in ARM assembler?!

Yes, StrongED is 100% ARM assembler.

Why is the standard font set to a bitmap font? That might appeal to retro programmers but not to any other.

Because that’s what it was designed for. Outline fonts were added very late on, and initially only for printing as most modern printers no longer support text mode printing.

However, as printing on RISC OS is very similar to screen redraw I decided to try using outline fonts for screen redraw too. And it works surprisingly well but it’s not without issues.

Well that looks that we need to make a big cut about the RISC OS Clipboard system. If it is unfixable how it is now then we have startover and make the best one that is out there. And all maintained program can implement the new system and for the old ápps the old clipboard should be still present.

No, just no.

The data transfer protocol is difficult enough as it as. We don’t need yet another protocol to implement and maintain. The clipboard works fine for its original purpose (data transfer). It’s applications trying to track of the clipboard contents where problems show up.

Maybe Fred could be persuaded to make the LoW act like a tree, or he will come here and tell me it already can. ;-)

I’d have to investigate if and how LoW could be changed to display as a tree which would also show objects currently not loaded. If StrongED were a Toolbox application then the TreeView gadget would make this easier but it’s not.

What I can tell you is that LoW is no longer limited to the (IMO ugly) system font. You can now use an outline font, same for LoF and throwback windows. :-)

This does pose a restriction, programs can’t be written as freely as they can in BASIC.

The BASIC interpreter, when it comes across a function or procedure whose name it has not yet registered, scans the program for a DEF FN or DEF PROC statement that matches the name, to register it in the appropriate linked list for quick look up if it should be required again, or else raises an error if none is to be found. This is made possible because, in BASIC, function/procedure definitions are not the same as assignments. You cannot rename, or give another name, to a function or procedure. The name and the value are indissolubly wedded.

The Lua interpreter, by contrast, if it encounters a variable-name that is neither that of a local variable nor in the current environment, simply assigns it the special value nil. On the face of it this would seem to make mutual recursion impossible. But there is a way round this if the values in question are both functions and local to the same chunk, or indices in the same table.

In the first case

local f, g
function f (...) .... g ..... end
function g (...) .... f ..... end
..... f & g called further on ....

In the second case,

x = {
f = function (self, ... ) ...... self:g ..... end;
g = function (self, ... ) ...... self:f ..... end;
}
..... x:f ( ... ) .... x:g ( ... )

But, if the two functions do not belong to the same chunk, or the same table, if they were defined in different files for example, there is no way that they can call each other as far as I can see. AppBasic implicitly uses mutual recursion: the main part uses user-defined procedures, which in turn must use stuff defined in the main part (error-handlers, for example). I have not seen a way that Lua can handle that. I would be grateful to be shown wrong.

An essential part of Lua is that functions are values like any other, and so a function definition is just an assignment of a value to a name. You can give a function as many different names as you like, or use it without giving it a name at all. For this reason, BASIC’s eager lookup behaviour is not feasible for Lua.

Adding support for the IDE is fine so long as StrongED can remain a single application. It’s just a hobby and I don’t want to maintain 2 versions.

This. I would say this is the essence of a good plugin framework. Define an interface consisting of must-have and optional components, and then leave the developer of the plugin to develop it as he or she sees fit. As long as the interface doesn’t change, and the plugin implements all of the must-haves, the developer of the plugin can extend or expand its capabilities wherever the whimsy takes them, or not at all.

@Steve Drain

I was interested in this, but I do not understand what it is. Could you explain more, please?

If attached an example to create an application a RISC OS desktop application. The program belongs to 7th software, thanks to them, but it illustrates the principle well.

The file contains the development directory, conforming to DDE rules.
Note this is a desktop application and there is a library.

The window you got.
One window for all files. Basic programs open in! StrongEd by clicking + the shift key.
The Make button is not very useful in Basic, but there may be a specific command in the makefile.
The Inst button, using the makefile file, will create the application with its directory, just one click. For the demonstration the application is installed at the same level as the development directory.
MKCl button clean the application directory.
It all works with the DDE environment.

To come back to your question, a desktop application uses objects created with ResEd or WinEd.
These tools only know them by number, so we associate them with a much more meaningful name.
In the application below, it is not used, it directly creates the objects from the numbers, I think.
I am using ResEd but I will modify my program so that I can also open the Templates files with the Res button If WinEd has been seen by the filer.

https://jeanmichelb.riscos.fr/Temp/BasicEx.zip

Note: I like !StrongEd as it is, if you select an already open development file, !StrongEd brings it back to the foreground, which also works fine with the window list.

—
Jean-Michel

These tools only know them by number, so we associate them with a much more meaningful name.

That is the bit I do not see. In my tests and the example you have given the Res and Comp buttons are greyed out.

As far as I can tell from the Help file, the names of components have to be already defined in a header file, or does Diderot create that?

I certainly agree with the idea of pushing some existing ‘standards’, such as the DDE-style folder structure. I know some don’t like the Toolbox, but it is better for beginners. Taking advantage of existing software like StrongEd will surely make this project more achievable?

If anyone wants to start from zero, and basically build VB/VC++ for RISC OS, then fair play, but I think we will see multi-core usage before then!

Hello

That is the bit I do not see. In my tests and the example you have given the Res and Comp buttons are greyed out.

Yes,
I am using ResEd and the application is looking for a Res file, In the message file you can change the line
Res: Resources.UK.Res with
Res: Resources.UK.Templates
This works if the filer has seen an editor for this type of WinEd file for example. (Just tested …)
Idem for components
You must create a file that will contain this information that can be read by my program in C, it is a .h file (header)
ex:
/* Key shortcut Event Window */
#define KSC_quit_event 0×01
#define KSC_plus_event 0×201

Diderot is a simple information collector for the development of an application. This function could be fulfilled with ResEd, I don’t know where the development of the ToolBox is?
For information when you create an object with a tool like VB or VC you are asked to name it and this name is used to create the class (C ++) that goes with it.
Why not with RISCOS ?

I certainly agree with the idea of pushing some existing ‘standards’, such as the DDE-style folder structure.
I looked for a “direction” to be able to develop with RISCOS and I think that of ROOL is good, it simplifies the work.
By comparison, the IDEs of other OS also impose a structure on the development directory.

I know some don’t like the Toolbox, but it is better for beginners.

If you want to build an application the ToolBox is essential, and allows you to concentrate on the rest of the program.
I also think it’s the best way to attract developers who come from other backgrounds …

I agree the future is also multi-core and VFP with RISCOS.

—
Jean-Michel

If you want to build an application the ToolBox is essential

No it’s not.

I would hazard a guess that the non toolbox software is still in the majority. So I hope this IDE will also support regular templates as well as Res files.

Though, I will agree, this does depend a lot on the quality of your library. The one I use automates a lot of the Wimp dispatch plumbing, so when I last looked at the Toolbox (coverage circa 2000 or so) it didn’t really seem to offer much to justify making the transition. Yes, some generic dialogues are automatically handled. Now, if you want a dialogue like the standard one but with additional options, well, the toolbox wasn’t quite so helpful with things like that.

I agree the future is also multi-core and VFP with RISCOS.

Yes, the quicker we can swap FPE for VFP, the better.

For someone who likes maths :-)

In the message file you can change the line: Res: Resources.UK.Res

Ah! I see how it works now, with something similar for the Comp button. I was hoping for something automatic, so I think Diderot is not for me. ;-(

By the way, officially, a location Res file should not be put in, say, a UK directory, but should have a numeric suffix for the Country number. This enters the whole morasse of Territories, so I will say no more. ;-)

@Fred Graute

Yes, StrongED is 100% ARM assembler.

That is bad news as that would mean when we switch to 64 bit then we need to do another editor anyhow.
But it could save us some time at the beginning.
The question how easy is it to ingtegrate StrongEd into the IDE. When loading files should be not too difficult to direct to StrongED. IDE features need to be offered then by a free floating toolbar or is it possible to include the StrongED edit window inside the IDE window? …

@Richard Walker

I certainly agree with the idea of pushing some existing ‘standards’, such as the DDE-style folder structure.

Anything that is structured, clear and easy-to-use is welcome!

Toolbox:
If there is anything that needs to improved in Toolbox then this might be also part of the IDE job. As from the quality of the Toolbox the success of the IDE depends also.

But there should be options to make programs also without the toolbox.
The IDE should not be a limitation to the programmer.

That is bad news as that would mean when we switch to 64 bit then we need to do another editor anyhow.

I don’t see it as bad news per se.

SE would be a plugin and if Fred hadn’t reworked the source by the time 64 bit was the only option you would just use a different plugin editor.
Some people might want to use a different editor anyway.

Some people might want to use a different editor anyway.

Zap.

What, you think it’s a problem that Zap is also an impenetrable pile of assembler? That’s okay. By the time 64 bit becomes an issue, I’ll probably be gaga.
I mean, I’m already well on the way to being a Crazy Cat Lady Guy…

Zap.

Yep, that was top of the list, as was the person that mentioned it :)

Bringing us back to IDEs:

I think the thing to do would be to consult as to what users want, and what they want to do.

Users I’d classify into several categories:

1. Seasoned RISC OS programmers
2. RISC OS users who dabble in programming
3. People who haven’t programmed anything before
4. People who haven’t programmed RISC OS but are experienced programming other platforms

I’d then query what sort of programs each of those want to write, in what languages, and where they would appreciate an IDE to help them out. It might also be interesting to know what programming experience they have on other platforms.

I think you would find opinions quite divergent between those groups. I think that’s important to identify because you may need different things to cater to different users. For example a My First Program interface might not much to offer the pro who is expecting Mission Control, and vice versa.

Perhaps the things to focus on might be that which delivers something useful to each of those groups. Programmers will only invest the effort in learning your IDE (especially if they have to pay for it) if it offers a substantial improvement on what they already have.

Perhaps the things to focus on might be that which delivers something useful to each of those groups. Programmers will only invest the effort in learning your IDE (especially if they have to pay for it) if it offers a substantial improvement on what they already have.

+1 Although I would replace “Programmers” with “Users”
Well, actually, to repeat myself:

The tools should not only be easy to use by all including beginners, they should especially be usable by beginners.

and

So, simple to use and intuitive.
Let’s give the currently-not-programming users a shot at converting the ideas they have into something like functional code.

But that doesn’t mean it should adopt “My First Program” at the expense of usability for experienced folk.

if it offers a substantial improvement on what they already have.

I think that depends upon what you mean here. If you’re comparing with what’s on offer for a Windows and Linux, that’s a pretty high bar given the huge development efforts to create integrated and functional IDEs.
If, on the other hand you mean what’s available for RISC OS, well that’s not so much a bar as a piece of wire lying on the ground. ;-)

It might be worth talking to those who create their RISC OS software on other platforms in able to make use of the advantages of those platforms, rather than enduring the limitations of the essentially command line tools…

Sadly I’m used to the way the DDE works (could say I just don’t know any better…) but something that would be nice to have is local file version tracking. Every so often I dump the sources and resources into an archive as a snapshot of a given version of a program. But this isn’t terribly useful for making comparisons, and it is “when I remember”.
An automatic daily snapshot (if changed, obviously) that can self-diff would be useful.

I like Theo’s idea… Consider the different use cases.

If I had to pick one thing, it would be an integrated/visual source control interface (probably using git these days). That would create forks and PRs, and allow merging of PRs. A visual diff interface would help greatly, so we can clearly see what is in each potential PR.

With a nice visual diff interface, then I see no reason why it couldn’t also diff two things on the file system (so people who refuse to embrace source control can still gain something).

Coming up with a new language, or visual Toolbox code stub builder doesn’t excite me that much. I have used OSLibSupport in the past to write a simple Toolbox app, and thought it was OK. Code completion or documentation in tooltips would be more useful to me.