AppShell Appbuilder

[kamelito]

After listening to Eddy Caroll interview I read it's website and at one of the Devcon (uk for him) Appshell and Appbuilder were demonstrated. Is these tools ever released by CBM?
Any info etc?
Kamelito

[Matt_H]

I don't think these ever made it out the door. There's some info/code in the Commodore server dump that was circulating a year or two ago. The build of appshell.library in that archive is dated May 13, 1992, so I think this was something that CATS canceled, as opposed to it being ended by the bankruptcy. There's also an older release notes file (May 1991) that makes reference to appshell.library, appobjects.library, prefs.library, and hyper.library.

Of those, hyper.library is the only thing I recognize/understand, since it was an early name for what eventually became amigaguide.library. prefs.library appears to be an abandoned concept for a preferences system that was never fully implemented. I don't really understand what appobjects, appshell, and AppBuilder would have done.

Interestingly, there is also some archived correspondence from Inovatronics about AppBuilder, suggesting that Commodore may have outsourced development to them. I thought maybe AppBuilder eventually became CanDo, but the first release of CanDo predates all this work, so that's probably not the case.

[kamelito]

Il seems That it has been developed by David Junod.
"Dec. 93;Jun. 94 Section Head;User Interface Group, Amiga OS Development
Oct. 92;Dec. 93 Senior Software Engineer, Amiga OS Development
Oct. 91;Oct. 92 Software Engineer, Amiga OS Development
Oct. 89;Oct. 91 User Interface Standards Engineer, CATS

Maintained Intuition;, the base-level user-interface component of the Amiga Operating System.

Invented and developed DataTypes;, an object-oriented system for handling real-time multimedia (audio, graphic, animation and video) data.

Design, implementation and maintenance of many utilities and modules bundled with the Amiga, such as the Icon Editor and the CD-Audio player for the consumer-level CD-based computer system.

Close working relationship with several key developers, providing technical and user-interface design assistance.

Contributed many technical articles on Amiga programming and user-interface practices.

Given many public presentations at International Developer's conferences in Paris, Atlanta, Denver, Milan and Orlando.

Invented and developed the highly acclaimed AmigaGuide; hypertext system.

Design and implementation of a sophisticated reusable user-interface component library.

Invented and designed AppBuilder, a graphical application design and development tool.

Invented and developed AppShell, an object-oriented application development framework.

Key contributor to the state of the art in Amiga user-interface from 1989 to 1994.

Responsible for the Amiga User Interface Style Guide published by Addison-Wesley, interfaced with key developers, wrote the majority of the guidelines and coordinated the review process. Still available from Amazon.com."


 LinkedIn page:https://www.linkedin.com/in/djunod

[olsen]

I don't think these ever made it out the door. There's some info/code in the Commodore server dump that was circulating a year or two ago. The build of appshell.library in that archive is dated May 13, 1992, so I think this was something that CATS canceled, as opposed to it being ended by the bankruptcy. There's also an older release notes file (May 1991) that makes reference to appshell.library, appobjects.library, prefs.library, and hyper.library.

The AppBuilder/AppShell projects definitely floundered by 1992. If I remember correctly, our lot of commercial Amiga developers heard time and again about a set of powerful tools in development which would ease GUI design and application implementation work, we just had to wait a little bit longer...

One of these was the fabled "ToolMaker". It could be that AppBuilder and ToolMaker were different projects with the same focus, or overlapping focus, which eventually ran aground. Or they could be related.

"ToolMaker" and "AppShell" code survives in the archive, but there is no trace of "AppBuilder" code, only e-mail discussions on the subject remain, which go back to 1990.

Remember, the NeXTstep design and its tools ("Interface builder") had matured quite a bit by 1989/1990 and it got people thinking about object oriented design (SmallTalk style), the idea of frameworks, interactive visual tools for creating applications and their business logic, high resolution displays. Some of these ideas landed in AmigaOS, be it humble (the 2.0 new look, the A2024 monitor), not so humble (AmigaVision) or powerful (the BOOPSI architecture, AmigaGuide), there seems to be a direct influence from the NeXT.

The concepts used by AppShell and AppBuilder/ToolMaker might have sprung from the same source.

[kamelito]

On your opinion is there any good GUI designer tool? Back then à friend of mine wrote that Designer is by far the best.
Kamelito

[Matt_H]

David Junod would indeed be the one who knows what the story is. He's responsible for so many important AmigaOS innovations. He's even got a font named after him!

I wonder if AppShell eventually became SYS:Classes/ in Release 3? When did the A4000 ship, November 1992? I guess the six months between then and May 1992 could have been enough time to do that adaptation...

Eddy Carroll's DevCon writeup seems to imply that ToolMaker shipped, but I don't recall seeing on the Dev CDs. Maybe Commodore UK made it available? The Dev CDs seem to be built from CATS US material, which could explain its absence there. From what I can gather, it seems like AppShell/AppBuilder were to be the new-and-improved iterations of ToolMaker. I still don't understand what AppObjects was supposed to be.

There is a build of ToolMaker in the server archive from July 1992. It's definitely a 2.0-era program - no NewLook menus, doesn't use the display database for a screenmode, and it isn't font sensitive. It seems like it would have been a "good enough" tool but not a "great" tool that advanced the state of Amiga UIs. Something new would have been required for the 3.0 era.

As far as actual available UI tools, Hollywood/Designer seems quite capable and there are a few UI toolkits specifically designed for it, including an MUI interface. But Hollywood is a bit resource-heavy. On the traditional side, there's GadToolsBox. I think there was also something called ReActor for building ReAction UIs.

[Matt_H]

Did some more digging and found that AppShell was written up in the 1993 DevCon notes. It was to have provided a basic application framework with access to ARexx, AmigaGuide, new IPC standards, prefs, and other elements, the idea being that developers wouldn't have to implement all this stuff manually (incidentally, this also explains the cross references to hyper.library and prefs.library). Moving those functions to a shared library would also cut down on application code size.

AppShell sounds similar in some ways to OS4's application.library, which I always had a hard time understanding - I don't see a (user-side) difference between application.library and commodities.library.

At any rate, my previous theory on appshell.library evolving into SYS:Classes/ appears to be incorrect.

The notes also confirm that Inovatronics was handling development of AppBuilder, explaining its absence from the Commodore server dump. They also say that Toolmaker shipped in 1992. Maybe I missed it on the Dev CD?

[olsen]

Did some more digging and found that AppShell was written up in the 1993 DevCon notes. It was to have provided a basic application framework with access to ARexx, AmigaGuide, new IPC standards, prefs, and other elements, the idea being that developers wouldn't have to implement all this stuff manually (incidentally, this also explains the cross references to hyper.library and prefs.library). Moving those functions to a shared library would also cut down on application code size.

That was the idea: we get a framework to build applications upon. In practice, however, we were left to our own devices.

For example, creating a working, consistent ARexx interface for an application is not terribly hard, but if you lack the necessary documentation (Commodore never shipped anything comparable to William S. Hawes' own ARexx manual and developer material, until it was already too late), you're stumped.

Building GUIs on top of gadtools.library was possible, and so was building your own user interface components through BOOPSI. At least the basic tools were available in Kickstart 2.0, whereas in the "dark age" preceding it you had to hand-craft every GUI right down to the look and feel of the building blocks. So, things were easier, but starting with Kickstart 2.0, you still had to hand-craft the GUI, but you no longer had to hand-craft all the building blocks yourself. Visual design tools, or frameworks for programmatically constructing GUIs were still absent then in 1990-1992. AppShell, AppBuilder/ToolMaker, etc. were needed, badly, but they never arrived.

The notes also confirm that Inovatronics was handling development of AppBuilder, explaining its absence from the Commodore server dump. They also say that Toolmaker shipped in 1992. Maybe I missed it on the Dev CD?

To the best of my knowledge, neither AppShell nor ToolMaker ended up in the hands of the paying 3rd party developers in Europe. No material pertaining to either can be found on the Amiga Developer CD (1992), nor on the more recent Amiga Developer CD compilations (1.1, 1.2 and 2.1).

ToolMaker promised to ease what at the time still required a lot of manual work: building an application from scratch, with a working, powerful user interface.

NeXTstep's "Interface builder" showed how you could do that, and the industry (Microsoft, Apple, IBM, etc.) quickly began adapting its concepts (results started materializing by the mid 1990'ies).

Had Commodore shipped even a modest tool for making this task a little bit easier, it would have resonated in the developer community at the time, on both sides of the Atlantic. As far as I can tell that event never occured. Commodore would have covered it in AmigaMail, for example, yet there is no so documentation.

Regarding that 2016 server dump: absence of material from that archive does not imply that it has been lost, or never existed in the first place

[kolla]

And then, in 1993, came MUI

[olsen]

And then, in 1993, came MUI

The little acorn from which MUI grew was MagicFileRequester, in 1992. Arguably, the asl.library rewrite of the same year (developer previews were available in the first quarter of 1992) already featured a dynamically generated GUI which took font, screen resolution and window size into account. But MagicFileRequester leapfrogged it with ease

[kamelito]

A friend of mine who was a CBM dev did have Toolmaker, it look like a 2.0 application. I'm not sure how good it was though.
Kamelito  update found this on usenet  https://groups.google.com/forum/#!topic/comp.sys.amiga.programmer/UObhRwAY_Vg

[kamelito]

A friend of mine who was a CBM dev did have Toolmaker, it look like a 2.0 application. I'm not sure how good it was though.
Kamelito  update found this on usenet  https://groups.google.com/forum/#!topic/comp.sys.amiga.programmer/UObhRwAY_Vg

 https://www.linkedin.com/in/michael-erwin-7bba6710

[Matt_H]

To the best of my knowledge, neither AppShell nor ToolMaker ended up in the hands of the paying 3rd party developers in Europe. No material pertaining to either can be found on the Amiga Developer CD (1992), nor on the more recent Amiga Developer CD compilations (1.1, 1.2 and 2.1).

ToolMaker promised to ease what at the time still required a lot of manual work: building an application from scratch, with a working, powerful user interface.

NeXTstep's "Interface builder" showed how you could do that, and the industry (Microsoft, Apple, IBM, etc.) quickly began adapting its concepts (results started materializing by the mid 1990'ies).

The trend really caught on. Nowadays, it seems like every other vendor on the planet is selling UI mockup tools for mobile applications.

A friend of mine who was a CBM dev did have Toolmaker, it look like a 2.0 application. I'm not sure how good it was though.
Kamelito  update found this on usenet  https://groups.google.com/forum/#!topic/comp.sys.amiga.programmer/UObhRwAY_Vg

So it looks like ToolMaker was released/available, just not through CATS. As a result, it seems to have flown under the radar of most of the people who would have benefited from it.

The little acorn from which MUI grew was MagicFileRequester, in 1992. Arguably, the asl.library rewrite of the same year (developer previews were available in the first quarter of 1992) already featured a dynamically generated GUI which took font, screen resolution and window size into account. But MagicFileRequester leapfrogged it with ease

And that little acorn is now also the native file requester in MorphOS. I love learning about the origins of these things

That was the idea: we get a framework to build applications upon. In practice, however, we were left to our own devices.

For example, creating a working, consistent ARexx interface for an application is not terribly hard, but if you lack the necessary documentation (Commodore never shipped anything comparable to William S. Hawes' own ARexx manual and developer material, until it was already too late), you're stumped.

Building GUIs on top of gadtools.library was possible, and so was building your own user interface components through BOOPSI. At least the basic tools were available in Kickstart 2.0, whereas in the "dark age" preceding it you had to hand-craft every GUI right down to the look and feel of the building blocks. So, things were easier, but starting with Kickstart 2.0, you still had to hand-craft the GUI, but you no longer had to hand-craft all the building blocks yourself.

Until just now, I hadn't even realized that MUI eventually mostly filled that gap. Just like arp.library and req.library in the 1.3 era, never underestimate the ability of Amiga developers to come up with their own solution!

Regarding that 2016 server dump: absence of material from that archive does not imply that it has been lost, or never existed in the first place

Indeed, it's only a partial backup. I hope someone has a full copy somewhere. It's an important historical artifact worthy of preservation. I know you have more, but I don't know if you have everything

[kolla]

The little acorn from which MUI grew was MagicFileRequester, in 1992. Arguably, the asl.library rewrite of the same year (developer previews were available in the first quarter of 1992) already featured a dynamically generated GUI which took font, screen resolution and window size into account. But MagicFileRequester leapfrogged it with ease

Well, today I happily prefer ASL (the OS3.9 one?), lean, fast and to the point. Some time ago I someone pointed out for me that AslToRT can work reversed, something that made me even happier

http://aminet.net/package/util/misc/AslToRT

[olsen]

Well, today I happily prefer ASL (the OS3.9 one?), lean, fast and to the point.

The asl.library file requester code in OS 3.5 and 3.9 is practically identical. It builds upon the asl.library rewrite which Martin Taillefer performed for Workbench 2.1.

The original asl.library (Workbench 1.4/2.0) is strongly related to arp.library. Charlie Heath, who also contributed to arp.library, wrote asl.library, too. It consists of some 6,500 lines of 68k assembly language code. Incidentally, "ASL" stands for "application support library", and some of its API functionality later migrated to utility.library.

Martin Taillefer rewrote asl.library from the ground up in 'C' (1991). The file requester cleverly mixes asynchronous directory reading with user interface operations, which makes it so fast and responsive. The only drawback was in that the list of file and directory names displayed were stored in a plain doubly-linked list, which was updated and sorted in real time as new entries were added to it.

The file requester would use straight insertion sort (red flag!), which scales very poorly. The more entries were added to the list, the more time was spent on finding the right place to put an entry.

Worst case behaviour would result if the directory entries were added in sorted order. This actually happened with ISO 9660 format CD-ROMs, for which directories are always stored and returned in sorted order. Not only was the CD-ROM drive slow, reading directories caused the asl.library to crawl after only a hundred entries.

This was one of the major reasons why there were so many utilities available in 1991-1993 that would replace the asl.library file requester by something faster (but not necessarily something more responsive).

The poor scalability of the asl.library file requester drove me nuts. I updated it for OS 3.5 by changing how the sorting operation worked. The doubly-linked list operations could not be easily replaced, so I came up with an algorithm which combined the list entries with a binary search tree. This combination speeds up the insertion operation, keeping the effort needed to maintain it sorted very small, regardless of how many directory entries there are (in CS terms: it went from O(n^2) to O(log(n)) complexity).

The same doubly-linked list sort operation, augmented by a binary search tree also wound up in workbench.library, for example.

With this improved list sort operation, the asl.library file requester became consistently both responsive and fast, not just for a limited number of directory entries.