GUIs abstracted

I am interested in an abstract description of
how one uses a GUI – say the RISC OS desktop
for definiteness – and wonder whether anybody
has formulated one.

One concept is ‘location’ this is basically
(window, icon) where windows have handles and
icons have numbers, with special values for
the iconbar and for backgrounds.

Another is ‘user-action’: pressing a key or
clicking a mouse button. See the possible
icon flags in PRM3 for the variety of
actions. Another, more complex user-action
is dragging an icon, either to a location
under one’s own control, or under the filer’s.

What a wimp program does amounts to ‘registering’
what happens when a user-action takes place
at a given location in a given context.
The available locations also depend on context.
When a menu opens suddenly there are more things
to click on.

I know that Gnome provided such an abstraction
from the days when I used a RisciX machine. Each
filer window could be furnished with a script
that specified how the window was to behave.
Did Acorn ever produce an abstract specification
for the RISC OS GUI?

No, the Wimp model was always monolithic and tightly bound. Psion’s Epoc model was that the UI and the ‘engine’ should be completely separate, as Epoc had more than one Gui available to it, but RO has always been hard-wired. Just look at the example programs.

A bit like the observation that every major application has (the equivalent of) a Lisp processor in it, a well-written application should have abstractions for window gadgets (sliders, drop-down-lists) or key binding (instead of hard-wired hot-keys).

I use key/menu/UI abstraction these days… but I did not in the past. Because there’s no help from the Wimp for such things, I think it’s rarely done – how many applications allow you to change the hotkeys easily? It requires menus to be created differently for a start.

RO has always been hard-wired.

That certainly seems to be the case. I am interested in what data-structures would be most appropriate for Wimp programming. By appropriate I mean which would present the simplest conceptual model for users. The toolbox fell rather flat from this aspect – well it also cost money, of course.

what data-structures would be most appropriate for Wimp programming

You don’t really have a choice. The PRM describes the structures that are passed to the Wimp and… that’s that.
It can be quite nicely handled in C thanks to the union keyword, where the Wimp poll event structure is what it needs to be in response to the current activity. In BASIC, it’s a lot of fiddling around with wimp%!<offset> but in C it can be given nice names.

the simplest conceptual model for users

Users or programmers?

The Wimp is fairly simple. There’s a window (it has a unique handle) and the window can contain icons (numbered). They may have specific attributes (click, double click, ESG groups), however when something interesting happens you’ll be notified via the polling mechanism. An icon clicked? The Wimp will tell you window and icon…
Things are a little more complex with nested windows, dynamic window content (creating icons on the fly like Filer) and so on, but the basic principle remains.
It’s worth noting that the Wimp is entirely reactive (as is much of RISC OS). While the Wimp will cycle the active tasks, what happens at any given time is almost entirely dictated by external events. Icon click, key press, poll word from hardware, etc.

The toolbox fell rather flat from this aspect

I never really understood the point of the Toolbox. It didn’t extend the Wimp, it didn’t do a whole bunch of magical new things. It simply added a layer in between the traditional Wimp interface and the application. From things I heard back when it was introduced, it seemed that it was easier to use for the things that it could do, but the moment you wanted to go “off script” with some special behaviour, it got in the way more than it assisted. In the beginning I built my windows by hand, then I used a template editor and got to know how the Wimp behaved. I didn’t see that Toolbox offered me anything special – indeed the last I looked, its concept of internationalisation followed the traditional Acorn logic of “do as we say, don’t do as we do”…

When a menu opens suddenly there are more things to click on.

Certainly. But on the other hand, menus can change depending on what “menu” was clicked upon, and we don’t waste screen space by having menus (which are probably one of the lesser used parts of a window) always visible all the time. You can see from recent Linux that UI designers are struggling with this quandary – a menu in every window like traditional Windows? Or should it be a menu across the top like traditional MacOS?
RISC OS answered this problem by simply getting rid of them. They’re available when they’re needed, but don’t clutter windows otherwise. Of course, RISC OS newbies need to be told they’re there, they don’t have the crutch of having the menu always visible. But, then, there are numerous things RISC OS does differently so a little introduction mightn’t be a bad thing?

Personally, I think the Welcome Guide should be augmented by a Quick Start Guide that assumes the user knows how to use a UI and just concentrates on the primary differences. The Welcome Guide is good, and important, but it is best as a reference to a user interested in using RISC OS. A newbie would likely rather read twenty pages than try to find what they require in several hundred. And, of course, there’s no reason why the little guide can’t refer to the big one. I mean, they aren’t both going to describe how to use Edit, right?

You don’t really have a choice. The PRM describes the structures that are passed to the Wimp and… that’s that.

I think Gavin is after some abstraction rather than how to map that abstraction finally to the WIMP.

I still believe that, after getting to know plain WIMP (with home-brew lib), Toolbox, Qt, GTK, wxWindows, SWT, Swing, JavaFX, Vaadin and Wicket that it is extremely difficult to get to a well-working abstraction for all the GUIs in the different operating systems.

For desktop systems, I think that Java Swing does the most things right amongst the various technologies listed above. It suffers from Java as a language because it exists since Java 1.1 when Java still lacked even more of the basic abstraction features. And of course that someone decided that it should extend AWT concepts. I like Swing’s comparatively strict model-view-controller separation and the “Action” concept where you define one “User Action” and can create action buttons, menu items and toolbar buttons all automatically synced to the Action’s state (enabled, shortcut, mnemonic, text, icon…).

For the WIMP, I think the Toolbox is not such a bad abstraction. But if you include modern UI concepts from more advanced applications and, even more so, from more advanced foreign UI concepts, it gets a lot more complicated. RISC OS and its applications usually lack completely any kind of dynamic layout (see “layout manager” in Java Swing), and an old saying amongst UI developers is “programm the UI in one day, then fight one week to get the layout right”.

I never really understood the point of the Toolbox. It didn’t extend the Wimp, it didn’t do a whole bunch of magical new things. It simply added a layer in between the traditional Wimp interface and the application.

I think that the point of the Toolbox was “do something more advanced more simply in any programming language you like”. But it was half-hearted.

It has better abstraction than directly driving the WIMP. It provides some things that every app needs with a minimum amont of work (menus, iconbar icon, D&D-enabled components, “About” dialog…). It provides a more advanced template editor that allows some things to be wired via a GUI instead of spelling it out in code (a GUI builder if you like).

And it has the concept of gadgets – but stopped short of being useful here because the gadgets it provided were so simple that rebuilding them with plain WIMP was easy enough. The Rik Griffin gadgets (tree and tabbed view) give you an idea on what would have been possible.

Basically, the Toolbox was “too little, too late”. The experienced developers already had their own WIMP lib which did everything and more than the first Toolbox version. Acorn were not very eager to fix the bugs the developers reported, and insisted on selling the Toolbox stuff only in a bundle with the pricey DDE (which immediately subverted the idea of having it accessible to BASIC!).

Back in the heydays of Usenet there was a great Toolbox critique by Mark Wooding of Straylight, which summed up the main problematic points. Never found it online though.

I think Gavin is after some abstraction rather than how to map that abstraction finally to the WIMP.

Let us say that I dream of a situation where the Readme file for a Wimp application is executable, is its !RunImage in fact.

Let us take the business of dragging icons. If an icon is draggable let us say that the program can associate a drag-object to it. What kind of an object does that have to be? The important thing about dragging an icon is where it lands: either in a location belonging to its own task or in a filer-window. So a drag-object has to be a function of that. Its argument is supplied by the window-manager, of course, and its value is the action that one has programmed it to do; and that may well be a function too. So this tells us that we definitely need a higher order language to express this concept properly. BASIC or C will not cut it. A menu is a pair consisting of the name to be displayed at the top and list of items which are (name, action) pairs, and so on. I would like to formulate all this algorithmically in a sufficiently expressive pseudocode that does not mandate any particular programming language (but may rule some out), which shows the essential functional dependencies. There may be other considerations when it comes to implementation, naturally.

Take a peek at FrontEnd. ;-)

Let us say that I dream of a situation where the Readme file for a Wimp application is executable, is its !RunImage in fact.

That’s entirely possible now in fact, but I can’t see why anyone would want to execute half a meg of (say) Web Browser just to get it to print out half a page of help text.

The lack of an Acorn hypertext system (like StrongHelp) is an impediment. If that had been standardised in RO2 (much as CC half-heartedly did with !HyperView) then proper help/digital manuals would be commonplace.

The important thing about dragging an icon is where it lands

Which means that whatever is attached to the destination is as important is what is attached to the drag object. JavaScript (well, the DOM) has events that bubble up from container to container, ultimately to the ‘window’, and Windows uses a similar model at times. But there have been times, pages deep in a set of event-handler stubs that all call a shared implementation, when I wished for a simple icon number!

So, flexibility is the key, rather than one solution fits all.

I always felt that the Toolbox was an attempt to provide a (sort of) event-driven model for those who expected it, rather than (particularly) a way to do things that were hard manually.

And the problem with so many GUI toolkits is the sheer verbosity of them. I wrote a large application for Linux using GTK, and would often end up writing six or more lines of code to do what could be done in one line in RISC OS.

So this tells us that we definitely need a higher order language to express this concept properly. BASIC or C will not cut it.

Well, nonsense. Wimp icons support a Validation String, to which one can add fields that are significant only to your program. For example, ‘N’ is reserved for program use (but any top-bit-set character will do, none of those are defined now or ever will be). So in Basic one could therefore add NFNcallme(1234) to an icon and, when handling an icon click, get its Validation, extract the N field, and then do result=EVALn$ and hence call the attached function.

There are more efficient ways of binding event handlers to icons, but that requires very little code.

Steffen said

you define one “User Action” and can create action buttons, menu items and toolbar buttons all automatically synced to the Action’s state (enabled, shortcut, mnemonic, text, icon…).

Yes, it makes customisation much easier.

I’ve sometimes toyed with the idea of writing a layout system for the Wimp, but I’ve managed to think better of it every time.

you define one “User Action” …

That looks suspiciously like StrongED’s ‘Functions’ definitions, which primarily define the toolbar icons, but add action keys and menu items if required. As SH is written in assembler, I imagine the code to implement this is not simple. ;-)

Ditto Zap. Menus, buttons, keys, loads can be redefined.
Ditto assembler.
Ditto OMG implementation. ;-)

But, just as _swix() is awful code to look at, there is no such thing as a “simple” reconfigurable UI. The complexities are somewhere. The only real difference is… Where?

I think my soundbite about executable readme files was not clearly articulated, and so has been misinterpreted. Mea propria culpa. I grant that wimp programming involves unavoidable complexities. But it ought to be possible to comb these tangles out so that the complexities are hidden in a library module, and all that is left for the programmer is to spell out how the program is to be used.

The lack of an Acorn hypertext system

Why not HTML+CSS and NetSurf? That is good for most purposes. I prefer it to StrongHelp, in fact.

Well, nonsense.

OK. Any Turing-complete programming language can do it. But why be masochists? Remember, I am talking abstract structures here, not how to implement them in this or that programming language. BASIC and C cannot express higher order functions, except with makeshifts, which in the case of BASIC are grotesque. I do not think 12 bytes of an icon’s validation string quite give enough room for a useful piece of code ;). But I am probably appearing to take seriously what is intended in a jocular spirit. If so, my apologies.

Years ago I briefly used FastBasic on an Atari ST. This was quite impressive. It had coroutines. Code could be attached as leaves on the tree-structure of a wimp-object. It is a shame that Acorn did not incorporate menus and code in templates.

I do not think 12 bytes of an icon’s validation string quite give enough room for a useful piece of code ;)

It was a really long time ago I did some raw WIMP programming, but IIRC the validation string can be indirected (and some would argue that every icon should be indirected!) and therefore carry any length of data you (or the amount of available memory) like.

I wrote a library in BASIC that interpreted instructions in a binary file related to icon numbers in WIMP template files. These let you tie together icons to make things like sliders with attached numeric fields. If I’d written it in something more flexible than BASIC then I’d have used a textual description instead.

A few years later, having taken a brief detour to do some WIMP programming in C, I dropped the idea of having a BASIC library and wrote a framework in Python instead. Everything seemed a lot easier to prototype and build after that.

I believe FrontEnd was basically closed and proprietary Acorn stuff, wasn’t it?

I believe FrontEnd was basically closed and proprietary Acorn stuff, wasn’t it?

“Was” being the operative word, since the sources + docs are now in CVS (although maybe the DDE has some better docs or helper utilities)

https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Programmer/FrontEnd/

However in my experience it’s a bit crap and struggles with anything non-trivial. E.g. there’s no support for ESGs, and the SDCreate desc file has some arcane magic to control whether the Run button is enabled or not

However in my experience it’s a bit crap

A bit? It’s a “quick hack” to get command line tools working from a desktop environment.

Still, it demonstrates that something exists that allows actions on icons to be “scripted” (in a very simplistic manner).

I wrote a library in BASIC …

Oh yes! Here is my take on this topic. ;-)

No one has yet mentioned Object Oriented Design/Programming. It seems to me that the Wimp fits neatly into this concept, and I reckon that the Toolbox is the Acorn implementation of that, even if a bit ragged. I also think that it answers Gavin’s original question, so the abstract description is of Objects and Events.

When the Toobox was first introduced I bought the manual, but baulked at the price of the DDE to obtain ResEd etc. So I wrote my own in BASIC, implementing much of the same functionality with some extra Classes that were not part of the Desktop, such as files. Of couse, it was never finished. The method involved BASIC libraries for each class for methods, shared among programs with my Basil module. Class data, such as Templates, Sprites and Messages was also shared in ResourceFS using my RFSFiles module. The object data was in a block, used as a structure with named addresses. The namespace problem is the great limiting factor when trying to do this sort of thing in BASIC.

When David Pilling offered a version of Charm with ResEd included for a reasonable price I abandoned that project and not long after started writing Basalt, but I carried forward what it had taught me. When I came to include the Toolbox into Basalt I adopted a strict OO syntax, even though the SWI interface does not encourage that. ResEd is a both a design tool, but for the purpose of this topic is also a way the abstract description of objects and events may be specified. It is rather unhelpful when it comes to implementing this.

“Was” being the operative word, since the sources + docs are now in CVS (although maybe the DDE has some better docs or helper utilities)

Exactly. It was unavailable to me at the time it might have been interesting.

When the Toobox was first introduced I bought the manual, but baulked at the price of the DDE to obtain ResEd etc.

There’s a bit of a pattern forming here, isn’t there? ;-)

I ultimately gave up on using templates, though I thought TemplEd was quite nice to use, and got into constructing my own widgets. There’s a confusing assortment of paradigms on display in what I created but I learned a lot by doing it. The swi module in RISC OS Python enabled the interesting parts of the WIMP to be used and the rest to be ignored.

I do not think 12 bytes of an icon’s validation string quite give enough room for a useful piece of code ;)

It was a really long time ago I did some raw WIMP programming, but IIRC the validation string can be indirected (and some would argue that every icon should be indirected!) and therefore carry any length of data you (or the amount of available memory) like.

The 12 bytes is the icon data block, which can either be up to twelve characters of text or a 32-bit pointer to an indirected text buffer, a 32-bit length value for the buffer, and a 32-bit pointer to a validation string. Thus validation strings are always “indirected”, inasmuch as they can only exist in an indirected icon.

If there’s a length limit, I’ve never hit it. :-)

There’s no length limit.

From some time ago:

It is a shame that Acorn did not incorporate menus and code in templates.

There’s nothing stopping you. There’s several billion different types of thing that can be put in a Templates file, of which precisely one is defined: #1=Window.

GUIs do fit an OO framework—the problem is efficiently associating code with events. There have been many different ways of doing this. Java has its listener model—it appears to be accepted now, but was quite controversial at first. Qt extended C++ to get signals and slots, together with the meta-object compiler. MFC (and wxWidgets) use “event tables” — specialised comments.

I think .NET, with "delegates"— effectively “safe” function pointers — is probably the easiest to understand.