NEWS, EDITORIALS, REFERENCE

Homebase Applications

I need to keep myself from just writing all of my thoughts into one incredibly long post. So this post is more or less a direct continuation of where things trailed off in the previous post, Application Loading. Make sure you read that one first if you just happen to have stumbled upon this post.

I'll be the first to admit that the mobile revolution has reinvigorated me to explore new things with the C64. There are some great parallels and some interesting new opportunities. For a while the PC market just kept getting bigger, faster, higher resolution and it felt like the C64 was hopelessly left behind. But then something kinda neat happened. The industry transitioned from a focus on desktops to a focus on mobile devices. Mobile devices are much less powerful than desktops of the same era, but they also have much smaller screens. This necessitated rethinking how people interact with these smaller less powerful computers. The UI on the Apple Watch for example isn't just a miniature version of the macOS! That's the sort of insane thing that '90s Microsoft would have tried to do, but even they aren't that insensitive anymore to how a UI should work to best suit the form factor.

What a great and reinvigorating opportunity. The C64 has a low resolution, and a small amount of ram, a slow CPU, and well pretty slow disk access too. Not that that should get us down! It's charming and we love it for what it is. It's like an old shoe that feels great to slip back on. The mobile revolution has shown me that it isn't sensible to try to shove a 30" Cinema Display's UI into 320x200 pixels. In many ways Wheels' UI was a mistake compared to the GEOS deskTop with its notepad metaphor. Instead of a bunch of overlapping resizable windows like PCs have, GEOS should have been evolved to have more powerful tools without losing the simplicity and elegance of the notepad.

There are some ideas that come from here and there that I want to integrate into C64 OS, because I think they'll really work. One idea is from the Apple Watch. It's gotten panned by a number of snooty think-they-know-best bloggers. But I'm not going to pay any attention to them. The Apple Watch has two "Home Screens." They are two completely separate interface concepts, and they serve different needs. The first is the Watch Face. It's a collection of little snippets of glanceable information, but it's actually more than that. Each snippet of info is it self a button that can be tapped to launch the corresponding application. So, it's actually like a fancy custom app launcher. The problem is that even the most complicated Watch Face ("Modular") only has 5 customizable blocks, plus the time which doesn't launch anything when tapped. You can also make more than one face with different layout styles and swipe to switch between faces. So I have two modular faces that are side-by-side but they have different "complications." This brings the total up to 10. Switch between lots of watch faces each uniquely customized starts to become tedius and inefficient. Instead there is a whole separate UI designed just for launching apps.

The so-called Honey Comb. Many people have called for Apple to ditch the Honey Comb altogether. But that never made sense to me. I've got 37 apps that are accessible via the Honey Comb. Only a few of these are accessible via the Watch Faces. How else would one ever get to those others if not via the Honey Comb? Apple has justifiably downplayed its importance in the marketing, but they didn't get rid of it. When you press the crown, you switch between these two "Launchers." You're at the Watch Face? Press the crown and now you're at the Honey Comb. You're at the Honey Comb? Press the crown and you're at the Watch Face. When you're in one of the two launchers, pressing the crown switches you to the other launcher. Here's what's really neat though. When you launch any app, watchOS remembers which Launcher you were at last. From inside an app, you press the crown to quit the app and go back to the Launcher. Which Launcher? Whichever one you launched the app from. This makes a tonne of sense. Not kidding.

From the Honey Comb, tap Alarm Clock and you're into the alarm clock. Press the crown and you're back at the Honey Comb. Then tap Workout and you're into the workout app. Press the crown and you're back to the Honey Comb, and so on. But if you switch from the Honey Comb to the Watch Face, now watchOS remembers you're at the Watch Face. Tap a complication like Music, you're in the music app. Press the crown and you don't go back to the Honey Comb, you go back to the Watch Face, which makes perfect sense because that's where you just were when you launched Music. And so it goes. I think this is brilliant. Here's why.

The C64 has a very limited amount of memory, and a limited amount of screen real estate. Sometimes you want to just launch apps, and sometimes you want to manage files. The GEOS deskTop, and the Wheels Dashboard, along with the Windows Explorer and the Mac Finder, smashed the functionality of managing files and launching applications into the same UI. On big boy computers there is enough screen real estate (and memory) that Windows can afford to have the Start menu as a launcher, and the Finder can have the always present Dock, in addition to being able to open a window, find an application in the file system and double click it to open. But in GEOS and Wheels managing files and launching apps is smashed together into something that's not ideal at either of those tasks.

In WiNGs, the GUI didn't get sufficiently developed before neither Jolz nor I were really working on it anymore. However, mea culpa, I blindly started to add on metaphors from both Apple and Microsoft. I gave WiNGs both a Dock AND a Start Menu. Here's a shot of how that looked:

On the left you can see the two square 16x16 icons. The Commodore Logo, if clicked opens out a hierarchical menu full of applications. The Eye Ball is for the currently running application. SpiffyPaint in this case. Such a beautiful screenshot, I'm still very proud of SpiffyPaint. There is only one app running at the moment, but WiNGs is multi-tasking, so there can be more than one of those icons there indicating what's open and allowing you to switch quickly between them. In other words, this functions both like the "Dock" on macOS and like the Windows Start menu. However, it takes up an atrocious amount of screen real estate, and it was only possible because the SuperCPU gave us copious amounts of RAM. Many megabytes.

Two Homebase Apps

Homebase is not an application. It is C64 OS's internal reference to the application that will be reloaded when the current application is quit. By default, there are two Homebase applications that I am writing for C64 OS. "App Launcher" and "File Manager". These are full applications of their own, however they are never explicitly quit. Each one provides a way to switch to the other. Probably via a menu command. Switching changes the internal Homebase reference, and then loads and runs that Homebase app.

The essential characteristic of a Homebase app is that it allows for launching other apps. When an app quits, C64 OS reloads the designated Homebase app. So, for example, if you start in File Manager and use it to open a text file in "Text Editor", the following happens:

• File Manager is quit and given an opportunity to save its state.
• Text Editor is loaded and initialized, loading in its menu definitions.
• Text Editor has the opportunity to optionally load in previously saved state or configuration.
• Text Editor loads in the file specified for open by the File Manager.

Then when you are done with Text Editor and you choose quit from the menu, the following happens:

• Text Editor asks if you want to save changes to the open file. Which if you do it saves back overtop of the file it originally opened. It does this by using the file reference so that it goes back to the same device, partition, path and filename even if those have been changed in the interim.
• Text Editor is quit, giving it an opportunity to save its state, if necessary. Its own state and configuration are saved to files inside its own app bundle. It knows where that is because part of launching an app provides the app with the file reference to its bundle that was used to launch it.
• The designated Homebase app is then loaded (in this case File Manager).
• File Manager then restores its state taking the user back to the paths and devices where the user previously was, according to how File Manager saved its state.

In this way, Homebase works a bit like the Apple Watch's two launchers. It should be painless to use File Manager to navigate to the some part of the file system where you have a text file, open that text file using a text editor. Edit some text, save without needing to re-reference the file system or retype in a filename. And be returned to the File Manager exactly as it was when you left it. From there you could immediately open another application with another file that is in the same folder.

App Launcher

The App Launcher is like the iOS SpringBoard. It is not for moving or managing files. It displays applications which can be selected with the mouse or keyboard to be loaded and run. And because it is not burdened with file management functionality, it can offer a couple of convenient views for launching apps. It scans the "Applications" folder in the OS's system folder to find the list of all applications. Then presents them in a couple of ways.

• As a List (one line per app, sortable columns, showing name, filesize and "category.")
• As a set of Cards (2 lines per app, with a space between them, two columns of apps.)
• As a Desktop (Loads a background PETSCII art image, monochrome, and allows names of applications to be positioned arbitrarily around the screen. The background colour of app names are different allowing them to stand out from the background image.)

Here are a couple of mock up screenshots I've made to demonstrate how I think it could look.

This App has over 40k of ram to work with, but I honestly don't see it as being all that complex. I have a bunch of ideas for some pretty cool features. A Get Info option from the menus can display on a screen layer above the background layer a sort of "floating" info summary of the selected app. This will allow clicks that occur outside the bounds of the floating panel to pass through to the background layer. Allowing the user to leave Get Info open and click on different apps in the background. This panel could allow for changing some options on Apps. Each app's App Launcher settings are stored inside the App's Bundle in a standardized Homebase config file.

• Flag an app as a "Favourite"
• Flag an app as "On the Desktop"
• Set an app's "Category" keyword

In "Card" view you can then choose an option to only show Favourites. And in the "List" view the Category you've set becomes a sortable/groupable option so that Apps of a similar type cluster together. And when in "Desktop" view only those apps flagged as show on desktop have their name appear somewhere on the Desktop, as shown in the screenshot below.

Some other random notes and ideas: The ability to drag the names of apps around the desktop to place them in arbitrary positions, and then the start positions of app names on the desktop can be part of the Homebase config of the App saved in the App's Bundle. When the App Launcher is quit (either by switching to File Manager, or launching an app) the current view, and in List or Card view, the current scroll offset, and sort column and direction will be part of its saved and restorable state. This state will be saved back to the app bundle of the App Launcher app itself.

When the an application is double clicked from the App Launcher, the App Launcher builds a file reference struct, based upon the system's file reference struct, but with the additional path details to the applications folder and then the application bundle folder that is being launched. It calls the loadapp routine with this file reference.

The App Launcher has a menu option to Switch to the File Manager. When this option is chosen, the App Launcher has an opportunity to save its state. Then it builds a file reference, again from the system's file reference, but this time with "Services/File Manager" as additional path info. It changes the OS's Homebase references to "File Manager", which itself is saved to the OS's own main config file for next boot, and then it calls loadapp with the File Manager's file reference.

File Manager

I haven't put a whole lot of thought into the File Manager yet. Although, I did write a very full featured file manager for WiNGs, so I'm not unfamiliar with how they might work. Here's how the WiNGs one looks, for reference.¹ Then I'll talk about what will be different in C64 OS.

In short, the File Manager lets you navigate the actual file system. It lets you rename, delete and copy files. It also lets you launch applications, by finding an application bundle somewhere within the file system and double clicking it. Alternative, the File Manager allows you to start at a data file, that you find somewhere in the file system, and launch an application that handles opening this type of data. When this route is taken, the File Manager produces a file reference structure that points to the file to be open, and saves a pointer to that file reference somewhere in system workspace memory (within the first 2K of the C64's memory). After launching the application, the application checks to see if this workspace pointer is null. If it's null, there is no file to be opened. If it's not null, then it goes ahead and uses the file reference to open that file. It can subsequently use that file reference to write changes back to that file.

The WiNGs file manager was "two panel", stacked one above the other. The divider line could be moved up and down to change the ratio of space alloted to the two panels. It was implemented in the Soft-80 column text display. C64 OS operates in the standard 40 column text mode, so space is significantly more constrained. In the WiNGs text console, it was truly a text console only, there was no mouse support. C64 OS uses Text Mode for speed of rendering, but it activates the mouse pointer and otherwise interaction feels and behaves like a Graphical User Interface. WiNGs likewise did not have any standardized text based UI framework. And so all text rendering was being constrained to a single flat plane. There was no compositing, and so it was not possible to interact with anything under an overlaying dialog box.

Furthermore, there were no pulldown menus in the WiNGs text console, and no support therefore for putting keyboard shortcuts onto menu items. Therefore, the actual menu control of its File Manager feels very much like other C64 programs. The "menus" are haphazardly placed. Little snippets of key commands are specified in a bar at the bottom of the screen. And pressing the H key called up an overlay of a help screen that lists more key commands.

The underlying navigation is based on WiNGs' abstraction of the file system. In WiNGs the device that is booted from becomes the root of the file system, and all the other detected drives get "mounted" into a virtual folder in the root called something like devices. I actually forget now exactly what it was called. The ability of the File Manager in WiNGs to perform actions on files was backended on a set of commandline tools and framework APIs built into WiNGs. So, now let's talk about how things are different in C64 OS.

C64 OS operates in 40 column text mode. File names are 16 characters long. If we tried to display two columns side-by-side, there would be 20 columns per side. 16 of which are taken up by the length of a filename. Leaving just 4 characters for padding, a scrollbar, file type and file size plus any other marker for selection or file lock, etc. Basically, two columns side-by-side is not feasible. Two panels stacked one above the other is still an option, but in my opinion it is cramped and not ideal. It limits the number of possible "locations" to just 2. When you don't have a mouse, the idea is that you shift focus between the two locations, you navigate the file system independently in each panel, select some files in one panel and press a key to copy or move the files to the location in the other panel.

I think what I'm going to do instead is support "tabs." One row at the top, just below the menu bar, will be dedicated to tab names. Under each tab is a scrollable region that fills the rest of the screen and allows you to navigate the file system. You can create another tab, and possibly a third or fourth tab if memory permits.² Files will be selectable in a much more GUI like way. Click a file to highlight it. Hold shift and click a file to select a group of files. Hold Commodore Key and click to toggle selection of individual files. To move files to a new location you could then drag a selection of files to an open tab. There is a LOT of power in this. If you had 4 tabs open, you could have the other 3 tabs open to different locations and drag files to each different tab.

C64 OS also uses a compositing system. This means that there can be optional floating panels that open up, but that do not prevent the user from making selections and scrolling the content that lies beneath it.

But the most important difference is that C64 OS uses a standard menu system. So there will be no need for a help screen overlay. And no need for the key commands to have to be displayed in on-screen status bars. In fact, there is no need for every possible option to have a key command at all. For example, going up a directory could have a menu option that needs no key command. Nor does it need an entry in a help screen, it could just be an option in one of the menus.

Also unlike WiNGs, C64 OS's file system is not abstracted into a Unix-like tree structure. At the root of navigation are the devices and their numbers. And so in the file manager to go all the way to the "top" you will see a list of devices according to how they have been detected. My system would look like this:

• Dev #8 CMD HD
• Dev #9 CBM 1581
• Dev #10 SD2IEC
• Dev #11 CBM 1541

Clicking on, say, the Dev #8 CMD HD, based upon the type of device it is, it will load in the partition directory and display the partition numbers and names of the partitions much the way the above shows device numbers and device types. Ultimately, rather than building a uniform unix-like directory path, C64 OS and the File Manager together create and use file reference structures. Which I will discuss soon, in another post.

The goal of basically everything in C64 OS is to be powerful and make things feel fast. To me, this means that certain "mass operations" are a top priority of the File Manager. WiNGs is one of the only C64 programs (sure's it's an OS but you can think of it as a big fancy tool that you load up to do some task) that is able to recursively move whole directory branches from one device to another. Like from a RamLink to an IDE64, or from a CMD HD to a CMD FD, etc. Nothing else seems to support recursively moving directories. Wheels definitely doesn't. FCopy doesn't. The C64 OS File Manager has to.

Another mass operation like renaming files. Select a bunch of files and normalize the case. When files come from the internet they are often in mixed case, which, on a C64 looks like junk if you're in Uppercase/Graphics mode. But there aren't any tools that make it fast or easy to just change the case of the files to all uppercase. C64 OS's File Manager should be able to do this. Or just renaming one file. I want to select a file, press a key like return, type a new name and press return again to save the change. Boom. Fast. Wheels needs a whole dialog box to rename a file. Furthermore. C64 OS will have the ability to cut copy and paste text. GEOS can cut copy and paste text... but oddly, not inside the oneline text editor that's in a dialog box! In fact you cannot even move the cursor back into the middle of the file and remove some earlier characters.

In addition to powerful mass operations that make file management faster and easier, the File Manager will have the ability to open files by launching corresponding applications. The FileMan in WiNGs had this ability in a very light fashion. It could force open any file in the Ned text editor. It could zip and unzip files. And it could add .wav files to the WavStream play queue. But that WavStream queue thing was totally hardcoded, because I just happen to like digital audio. I'm not yet 100% sure how I'll handle it, but I'm thinking that the app bundle of each application will contain a file that lists the file extensions that application is capable of opening. A Sid player may list "sid" and "mus" for example. A koala image viewer may list "koa" and "koala". A Text editor may list "xml","html","text","t", etc. A digi audio player may list "wav" and "aiff". But, at the same time, a program meant to render and display HTML (in whatever limited fashion that may be) would also list "html". I think when the File Manager first runs it would read through these application extension files and build an index of extensions to application names. Perhaps it would cache these to a file stored in the File Manager's bundle with the ability to rebuild this list on demand. When you start with an HTML file and want to open it, since the File Manager knows of two applications that can handle HTML files, it would give you the ability to choose which application to launch.

That's it for this post. Next Post I will dive into C64 OS File Reference structures. And perhaps we'll look at the code for prepdisk and blksize. Both good routines that I've tested and which are working well. Soon after that I think I'll write a post about the Drive Detection routine in C64 OS. Stay tuned.

1. I knew there was a reason I still maintain wingsos.org. Actually, it's because it is a piece of Commodore History that is very dear to my heart. I've paid for the domain and hosting for years. I just, don't have it in me to take it down. [↩]
2. Limiting the number of entries in a directory, frankly, is the best way to conserve memory. At 16 characters per filename, 256 directory entries would use 4K of memory. But in fact it would use a bit more, because it needs 2 bytes for the file size and 1 byte for the file type. Which brings usage up to just under 5k for 256 entries. [↩]