Creating the Ultimate GUI
|
Posted on 8 September 1998
The following text was written by Philip
Gossling: Here are some ideas I thought up over the past year that I would
love to see in future GUI shells for the TI-86. Your eyes will also be entertained by the
cool screen shots I've included! :-) I actually tried making a GUI with the ideas below, but
I wasn't as good at ASM then, so I quit the project, and now I'm too busy! So I'm throwing
out my ideas to anyone who will take the bait :-) 1.
PRACTICAL USER INPUT. A shell on a calc should be built with a calculator
keypad in mind, not a mouse. My shell would use no mouse pointer. F1 would always be the
Start menu. F2-F5 would be the categories of programs, with F2 being the Desktop (the
first screen you see when starting the program), and then Games, Math and Utilities. The
arrow keys move a highlighting bar that highlights the programs, and 2nd runs the selected
program. Key input in the shell should be simple and fast, with nothing that wouldn't
really be feasible for a calculator. 2.
ICONS. Lets face it, icons are cool. So far these have only been experimented
with in Aurora, which was too slow and impractical. Icons however can still work on a
calculator. If I remember right, Aurora used 8x8 sprites placed above the program name.
This wasn't very smart. This layout just doesn't work on the 86 screen very well. However,
If you make the icons 7x7 sprites and place them to the immediate left of the program name,
you can fit lots of prgm names on one screen. You could also have the screen scroll down to
fit more programs. The shell should also have a built in icon editor that would attach
the icons to a program, so icon files wouldn't clutter the RAM. Icons should be able to be
attached and detached from files. If a program has no icon with it, the shell should
provide it with a temporary built in icon according to the file type. The shell should
also have a small icon library so users can choose from pre-maid icons that they can assign
to variables. Users could also add their own designs to the library. Now wouldn't that be
awesome :-) | 3. START BAR. Notice the
Windows-like Start Bar at the bottom of the screen in the shell screenshots. You'll notice
it displays different info in each screen shot. This is an interesting concept I came up
with. The bar could be personalized to have quick jumps to categories using the F2-F5 keys,
show a clock, the Free RAM, the date (if a clock was made), and more, maybe even a special
welcome message. If you want to do some quick calculations and stay in the shell, then
press F1(Start) and select the Calculate icon to do some math, and the start bar will
remain on the bottom of the screen, allowing you to stay in the shell and run progs
quickly. The math you could do would be limited though. If Windows add-on programs were
created for the shell, they could leave the start bar on the screen and just display the
program output above the bar. 4. TIME CLOCK. I think this is possible
to do, though I don't know exactly how it would keep accurate time when running an assembly
program. If it was done, you could display the date, have calendars, and have schedule
programs, etc. Maybe even a calculator-based student planner. You could also change APD
settings or see how long a program would take to run....(just some ideas). | 5. EXPLORER. A Windows explorer
for a calculator? I though this shell was supposed to be practical! An explorer would be a
great addition to the future GUI shells. My concept (see screenshot) is called RAM
Explorer. It allows you to view, delete, and get info on EVERY TI variable in the RAM (not
just programs). By clicking on the RAM icon, you can see all the variables, displayed on
the right, and info about the RAM (mem free, etc.). You can move these files into folders
that you create to organize them. How will folders work? Easy! My concept of a folder is
simply a TI string variable with a header that lets the shell know its a folder. Then after
the header, the string contains the names of all the files in the folder. The shell then
searches for these files and displays them! The RAM Explorer can be personalized to show TI
variable's built in icons (see icon screenshots) or variable type (as shown in screenshot
above) or variable size, or both. You can also use the STO-> key to move variables or
folders to other folders or the category folders like the Desktop. Explorer would also have
a built in linking program so you could receive stuff or send whole folders' contents to
other calcs. Also, when receiving a huge program with tons of sub-programs and variables
(like many TI-BASIC games), the Explorer will automatically create a folder (if you want)
that contains all the variables downloaded. Then if you hate the program and want to erase
it, you just delete the folder. No more will you have to search through 98k for all the
variables the program used to be sure its all out of the ram! Talk about useful! Talk about
cool! | 6. STRING VIEWER AND EDITOR. (This is
what the Notepad program is for) The GUI should have the ability to view strings in a
window in menu-text and provide the ability to edit the string or create a new string with
menu-text. There would also be formatting characters like the new-line character. With
icons added to the strings you could personalize them, like make help files, etc.
7. EMULATION. The GUI has to have emulation for the TI-82, TI-83 and TI-85.
This is the standard was set by ASE and Rascall, and should definitely be included in all
future shells. The shell should assign icons to emulated programs. 8.
COMPRESSION. The ability to compress and uncompress strings and programs.
9. WINDOWS PROGRAMS. The Ability to create programs that will run as if
they were integrated into the interface. They will run in windows, and the start bar will
remain on the screen. This is simple to do, but the program's output must be above the
start bar and the program must have input routines to activate the start bar. You could
also give programmers the addresses in the GUI of the time and where other useful info is
stored. 10. COMPONENTS. If you want WindowsCE without the Explorer,
or without the text editor, or you just want emulation and a desktop, then just erase or add
the components you want. The GUI should NEVER have the Explorers and Icon Editors and so on
built in. The shell should search for these programs on startup and if they are not there,
then the program will still run fine, you just wont have those abilities. This will allow
users to customize the size of their shell to fit their needs. Wouldn't all this
stuff in one GUI be huge? Anyone who is knowledgeable in ASM would see that all these
things can be accomplished in probably under 10k. And remember about components.
That's All for now. If I come up with anything else I'll update this article. Please post
questions, comments, and ideas for what you would like to see in future GUI shells. Also,
If anyone wants to create a shell like this (maybe create a programming group) then let me
know. I am a good artist and graphic designer who is also knowledgeable in Assembly. I just
don't have time with college and a full time job to create a shell like this myself. I
will help with art and ideas if you need them.
|
|
Reply to this item
|
*** ARTICLE UPDATE ***
|
Philip
|
Thanks so much for the positive feedback.
I've tried to answer as many questions as possible by posting responses.
If you guys come up with any new ideas, I might consider updating the article and including your ideas in the new article. Then the article could be a shell "resource" to let the programmers know what the TI community really wants in a shell!
I've also thought of 2 new ideas over the weekend:
1. AUTO COMPRESSION/UNCOMPRESSION: The abiltiy of the shell to recognize if a file is compressed and then automatically uncompress it. With this you could compress every program in the RAM and then the shell would uncompress the program when run, and then compress it back when finished. It would take a little longer to initially run a program, but thats the price you would pay for more free RAM.
2. QUICK ICONS. I noticed the start bar was kind of cramped so I figured I could replace the ASE type categories with Icons representing them. Then you could fit the start menu button, about 5 or 6 category icons, and the Free Ram all on one bar.
~Philip
pmadsen@juno.com
|
Reply to this comment
|
9 September 1998, 08:44 GMT
|
|
Why Windows?
|
Emmanuel
|
I like your presentation of the problem, but I have to say...I've got some major problems with your solution. WindowsCE, for example, is not doing spectacularly well. Why not? Well....Microsoft is making the same mistake you seem to be: that an OS that works on a computer will also work on a palmtop. Yet the TI is intrinsically different from a computer. So how can we assume GUI paradigms (which take years of research to be done right) can just be dumped to any platform. For heaven's sake..this is a calculator, and we should be thinking of innovative new ways to make a calculator OS. Is a clock necessary? Why a start menu? There are simply not enough files capable of being stored that would require a complex hierarchy. And even if there were...menus are designed with the assumption that screen size is not an issue. I think that in order to design a really kick-ass OS (GUI or not), we need to do two things:
1)Identify the needs of a TI user, or any calc user for that matter.
2)Identify the limitations in screen size, speed, memory, etc...
3)Given step 1 as an upper bound and step 2 as a lower one, make an OS that fits somewhere in the middle, combining the most features while living WITHIN the limitations of a calculator. Shells like ASE and Fargo do this very well.
4)Given how amazing talented some of the programmers are, use the free memory to add other features that are not a requirement. For example-dynamic loading of assembly drivers for serial devices (a QuickCam drive couldn't be that hard..could it?) OK..I'm going blue-sky, here. But that's ok. Step 4 should be done LAST...not first.
I think there's no limit to what we have the capacity to do. I've written Wireframe Renderers in basic that take up 460bytes, and are nearly as fast as a 92. These things are possible, but we need to start from the ground up. Starting from scratch seems to be a theme in the TI community, and it's one that adds tremendous enginuity and innovation.
Let's keep the flame alive.
Emmanuel
|
Reply to this comment
|
9 September 1998, 15:55 GMT
|
|
Compared to the TI89
|
min idzelis
|
Of course, the ti89 has most of those functions built in... Instead of compression, it has archiving, which puts variables/programs in a area separate from RAM which holds even if all batteries are taken out! String editor? The ti89 has one built in...
When do you think the first ASM programs for ti89 will come out?
|
Reply to this comment
|
9 September 1998, 16:13 GMT
|
|
|
|
|
Re: Compared to the TI89
|
anonymous
|
Hey, the type of memory the article above this one is called flash memory. I'm not saying the Flash tm type of thing, in TI-92 pluses, 89s, and 73s. For those of you who have played old Super Nintendo RPGs that have saving, some use flash memory such as Final Fantasy III, or at least the version of FF3 my friend has, and it takes about two to three seconds to save your game. Now, I've examened these save files on my computer, and their less then 100 bytes. Now, translate this to TIs. 5 and 6 kilobyte files will take forever. More than two minutes for 5k of data (at least on the TI-89 I used...).
|
Reply to this comment
|
28 September 1998, 01:13 GMT
|
|
|
|
|
Re: Compared to the TI89
|
anonymous
|
Hey, the type of memory the article above this one is called flash memory. I'm not saying the Flash tm type of thing, in TI-92 pluses, 89s, and 73s. For those of you who have played old Super Nintendo RPGs that have saving, some use flash memory such as Final Fantasy III, or at least the version of FF3 my friend has, and it takes about two to three seconds to save your game. Now, I've examened these save files on my computer, and their less then 100 bytes. Now, translate this to TIs. 5 and 6 kilobyte files will take forever. More than two minutes for 5k of data (at least on the TI-89 I used...).
|
Reply to this comment
|
28 September 1998, 01:15 GMT
|
|
|
|
|
Re: Compared to the TI89
|
anonymous
|
Hey, the type of memory the article above this one is called flash memory. I'm not saying the Flash tm type of thing, in TI-92 pluses, 89s, and 73s. For those of you who have played old Super Nintendo RPGs that have saving, some use flash memory such as Final Fantasy III, or at least the version of FF3 my friend has, and it takes about two to three seconds to save your game. Now, I've examened these save files on my computer, and their less then 100 bytes. Now, translate this to TIs. 5 and 6 kilobyte files will take forever. More than two minutes for 5k of data (at least on the TI-89 I used...).
|
Reply to this comment
|
28 September 1998, 01:14 GMT
|
|
Re: Article: "Creating the Ultimate GUI"
|
Andrew Hockman
(Web Page)
|
Ok, here's my $.02
The basic idea of expanding the range of the TI is a good idea. However, I have a couple of nits. First, why is it a requirement that everything look like Microsoft??? Let's make our own GUI, and save the Microsoft stuff as a non-integral shell that could be added/deleted for wow-factor. Also, how about breaking the program up into componant parts, and distributing the source along with the program? That way, the GUI would take on Linux properties where every user could modify, recompile, and use whatever "flavor" of GUI suits them best. I talking about segmented, WELL-DOCUMENTED code here... it would be a pain, but very rewarding in the end.
|
Reply to this comment
|
9 September 1998, 21:44 GMT
|
|
Re: Article: "Creating the Ultimate GUI"
|
Andrew Hockman
(Web Page)
|
Ok, here's my $.02
The basic idea of expanding the range of the TI is a good idea. However, I have a couple of nits. First, why is it a requirement that everything look like Microsoft??? Let's make our own GUI, and save the Microsoft stuff as a non-integral shell that could be added/deleted for wow-factor. Also, how about breaking the program up into componant parts, and distributing the source along with the program? That way, the GUI would take on Linux properties where every user could modify, recompile, and use whatever "flavor" of GUI suits them best. I talking about segmented, WELL-DOCUMENTED code here... it would be a pain, but very rewarding in the end.
One more thing. I've found that most of the Basic programs I use work much better from the home screen. Why must every asm shell insist on listing Basic programs? Again, customize...
|
Reply to this comment
|
9 September 1998, 21:45 GMT
|
|
Re: Article: "Creating the Ultimate GUI"
|
Jakob Perry
(Web Page)
|
I think this would be awsome! Who cares if its 10k, as long as it includes all those programs that are integrated into it. Keep up the good work!
Jakob Perry
|
Reply to this comment
|
9 September 1998, 22:29 GMT
|
|
Re: Article: "Creating the Ultimate GUI"
|
Brandon
|
I think the idea of a GUI is great. Now I'm not a asm programer but I a c++ one. I had an idea and I'm not sure if any one has thought of it, or at least not as much as I have. Lets say someone figured out how to use the calculators CBL to receive the x and y coordinates of a pen used on the Ti-Calc screen, the way I propose to do this is while the program is running, flash a dot on each pixel on the calcs screen, one at a time at a very fast rate. When the pen senses a dot that flashes it would check with the calc and see what dot was flash at that time, that way you could get the x and y coordinates of the pen. How would this be relevant you say, well you could use this in a couple ways:
1. I'm thinking of an organizer similar to a Palm Pilot and it would be much cheaper. You could have a sticky notes pad or navigate a GUI.
2. You could use it just to draw pictures, sort of a sketch pad, you could pick different shades of gray, and just draw when you want, not very useful.
3. You could actually make some sort of hand writing recognition program, but I don't think this would be useful either.
There are many diff. ways you could use it, I'm not a ASM programer (a novice one, but not very good) so I don't know the limitations. I just thought I would feed the ideas on doing new and inovative things on the TI. There are other ways you could find the location of the pen on the screen but I thought this one seemed the easiest.
I would love to hear any comments(hopfully positive).
|
Reply to this comment
|
9 September 1998, 22:41 GMT
|
|
|
|
|
Re: Re: Article: "Creating the Ultimate GUI"
|
Daladran
(Web Page)
|
While it's a nice idea, the practicality is null. How are you going to create this pen thingy? I doubt that it could be created by the everyday person at home. Even if the parts could be acquired at Radio Shack or some other store and a diagram was posted on the 'net, could a pens-sized object be created? Also, I'm relatively sure that if the wiring wasn't done correctly, the current overload through the CBL could damage some of the interal calculator parts.
Or maybe an individual or group will make the pens and sell them to others. How is the pen going to be distributed? An entire company would have to be created around this product to create the marketing, packaging, construction, and sample programs for this pen. Not only would this take an enormous amount of time and effort, but the price of the pen would skyrocket to compensate.
I'd estimate the price of this pen to be over 15 dollars. Who is going to buy a $15 pen for a calculator that costs $120? That's 8% of the cost of the calculator for a pen that allows you to "click" on part of the screen. Drawing pictures could be nice, but is it feasible in real-time? I ask the same question of the handwriting recognition programming.
Finally, there is the programming for the pen. What advantage is there of using a pen, for most programs? As far as I can tell, using the F1-5 keys, 2nd, enter, and exit works just fine. Not only this, but how much speed would be sacrificed to allow for the program to search for the x and y coordinates of the pen, not to mention the aesthics of the point traveling across each row down the screen.
I'm also a C++ and basic ASM programmer, so some (or all) of my inferences could be wrong. Criticize away.
Daladran
-Sorry for any grammatical and/or spelling mistakes; this took me too long to write so I'm not going to check it for errors.
|
Reply to this comment
|
10 September 1998, 05:45 GMT
|
|
1 2 3 4 5 6 7
You can change the number of comments per page in Account Preferences.
|