One conversation across the M100 email list mentioned doing a modernized version of the Tandy 100 "Model T" shell interface, running on a portable computer that is a modern version of the '100... which I'm sure you realize is exactly in line with where I am right now. ;) I picked this idea up and ran with it.3
I started by looking at the interface on my Tandy 102 (seen above), and seeing how it works, and the design used. I also fired up up the Virtual T emulator, which is a bit more convenient than having the real hardware with me. It looks like this:
It has an 8 line, 40 column LCD display. It's got the date in the top left, usually "(C)MICROSOFT" in the top right, since the firm/software was written by Microsoft by a guy named Bill Gates or something. (This screenshot is from the emulator, so it appears a little different than actual hardware.) The memory free in the bottom right, and the Select prompt in the bottom left, so you could just type in your selection. The middle area lists all of the files and programs in the ROM, mixed together.
I have started up a project on github called "Model T Shell", and have been exploring this. It is by no means finished, but I thought I'd bring you along while I experiment and hone the interface to something that makes sense and is reasonably usable.
I started out by doing the basics of it. It uses curses/ncurses/pdcurses, builds with gcc, and works on OS X (command line developer tools required), Linux (Ubuntu tested, requires ncurses), and perhaps in the future, a build on Windows/mingw.
I took the interface, added color, and made it flexible with respect to the screen size. Top left has the date and time in the same format (No more Y2k bug!). Top right is version info and username of the person running it. Middle section is navigated with the arrow keys, selected with "enter". Select prompt in the bottom left, and "free memory" in the bottom right. I wasn't sure what to put in the bottom right yet, so that's just a fixed string for now.
I added in a scanner for the current directory, and quickly realized that doing this was a horrible mess. I also had changed the bottom right to indicate what kind of 'thing' the selector was over. A directory in the above image.
Next, I figured I'd change it so that you had builtin tools in one section, then the current directory in the bottom section:
This wasn't quite right either. I think the issue was that I needed to separate them by what kind of thing they are, rather than where they're from. It needs to make sense for the end user with relation to workflows, or something. (Sidenote: This is exactly why my basement is a mess. Everything is in boxes based on where they were one or two houses ago, rather than their function.)
Next, I decided to separate it into three sections: Verbs, Places, Nouns.
Verbs are actionable things. This includes builtin programs and commandables, and current directory's commandables (executables, shell scripts, runnable programs.) Places are basically directory navigation. Nouns are things that can be loaded, edited, and such (files).
This seems to make sense for using. As you navigate around the directories, everything sorts as you would expect it to.
So... What's up next?
Next I'd like to change it such that the commandables and places have editable lists. That means that as you navigate around and find verbs that you like, you can add them to your verb list. Likewise, you can add places that you like to work from and store them there in that list.
I think that I would need to start with just a few commands and places there, and you could add them as you use the interface. The default commands might be: CONFIG (preferences), EXIT (leave the interface), ADD (adds a selected place or commandable to the lists), REMOVE (removes a place or commandable). As for places, mountpoints, and home directory.)
I also need to figure out how to let you select commandables for different files. I'm thinking maybe keying off of MIME types, or just more simply, file extensions. That way, for example, you could open .do or .doc files in PICO, but .txt files in VI or EMACS or whatever.
Oh, and it should also probably do something rather than just letting you navigate around the filesystem.
I don't see there being a final product, a single deliverable to achieve on this project... It's more of an exploration of how an interface like this might work for a modernish system. I'll post an update when I figure things out more.
No comments:
Post a Comment