SD: Re: DHOS Shell
[Prev][Next][Index][Thread]
SD: Re: DHOS Shell
This idea sounds like a good idea. I do have a few suggestions about how we
could go about performing some of the required ideas.
1) I like the idea of the common scripting language (your HTML example.) By
using an ASCII text like language, we can make use of some of the industry
standard tools for generating the scripts. We could spend less time writing
editors and just use emacs, notepad, ect.
2) HTML is not the method to proceed. I would suggest using XML if you don't
want a lot of overhead or SGML if overhead is not a concern. (For more
information on SGML and XML you can visit http://www.w3.org ,
http://www.sil.org/sgml/sgml.html or http://www.jclark.com.) Using XML/SGML,
we could make sure that certain structure was upheld. For example, a button
must appear inside of a dialog box.
3) By using a text based scripting, you also allow for the addition of
WYSIWYG editors for shells in the future. It would be simple for someone to
take an existing HTML, like FrontPage, and port it to use our set of
commands.
4) Text is smaller, can be transmitted over the Internet without error and
is one of the only true standards left.
5) If we ever needed to change the appearance, we wouldn't have to change
the entire scripting language. (This makes use of a common text processing
principle called stylesheets. We would define our own stylesheets and our
own document structure (DTD). We could then change them independent of each
other.)
6) There are numerous tools on the Internet for the processing of
stylesheets and XML/SGML. Best part is that they're all free. (See
http://www.jclark.com for an example of some of the best text processing
tools.)
I hope this brief email brought some of my ideas to the table. XML/SGML and
stylesheets are very complex and take months to master. It would be hard for
me to explain every aspect of the shell language that I'm thinking of.
I think that Matt had a great idea for using text strings to hold the shell
layout. This would be great to use. I would be more than happy to lead this
aspect if no one objected to using XML/SGML just due to the power of the
language.
Comments and Suggestions are Welcome.
~~ Dan Hable ~~
-----Original Message-----
From: Matt Cooper <mnemonicdevice@hotmail.com>
To: shell-developers@lists.ticalc.org <shell-developers@lists.ticalc.org>
Date: Thursday, August 20, 1998 7:21 PM
Subject: SD: DHOS Shell
>
>Hey all. I'd like to take a minute to talk about the shell for DHOS.
>
>My thoughts on this matter are that we create a scripting language with
>a compiler (for the PC, Mac, and Posix platforms) which renders the
>shell. Since the shell will be largely independent of the operating
>system, this approach will work better than shells for Usgard did.
>Every user can customize her own shell, rather than having to be a
>programmer to create a shell.
>
>I believe that when the OS boots, it should search for a string of a
>certain name. That way there is none of this "default shell" business.
>If no shell is found, check text memory for the name of a string to
>execute. If none is found, display ZShell-esque list of executable
>files.
>
>Here's my proposal for the shell scripting language. The reason I'm
>mentioning this now is because someone's going to have to write a shell
>compiler eventually. If you just want to have it convert to ASM, and
>then have the user compile that ASM, that'll work. Here goes:
>
>Basically just works like HTML. Flag on, flag off, line break, etc. So
>I'll stick to the HTML metaphor, however this could easily change.
>
><goto x=[x] y=[y] mode=[text/menu]> - Send the cursor there, either by
>row/col (text) or X,Y coord (menu)
>
><text>[text]</text> - Write in normal text
>
><menu>[text]</menu> - Write in menu text
>
><dispexe num=[number] alt="text if no prog found here"> - Display
>executable found according to number
>
><dispico num=[number] alt="text if no prog found here"> - Display
>executable found according to number as an icon
>
><tcr> - text carriage return (<goto x=[x+1] y=0 mode=text>)
>
><mcr> - menu carriage return (<goto x=[x+6] y=0 mode=menu>)
>
><region x=[x] y=[y] w=[w] h=[h] type=[caption/scrolling]>
>
>This one requires a little more explanation. A region is just a section
>of the window that can be defined. There can be only one "scrolling"
>type region in a shell. Basically, a "caption" window does not update
>(except through special libraries) whereas a scrolling region responds
>to "More" being pressed, as well as "Enter" and the arrows. Within a
>scrolling region, if "More" is pressed, the number portio of each
><dispico> or <dispexe> is incremented by the total number of <dispico>'s
>or <dispexe>'s found in it. If the arrows are pressed, the number
>portion is increased or decreased by 1. Wow, I just realized how
>utterly illegible that is. Let me just give an example or two:
>
>First, the ZShell shell would probably be defined like this:
>
><region x=0 y=0 w=127 h=10 type=caption>
><goto x=1 y=1 type=text>
><text>ZShell Version 4.0</text>
></region>
><region x=10 y=0 w=127 h=53 type=scrolling>
><goto x=2 y=1 type=text>
><dispexe num=1 alt=""><tcr>
><dispexe num=2 alt=""><tcr>
><dispexe num=3 alt=""><tcr>
><dispexe num=4 alt=""><tcr>
><dispexe num=5 alt=""><tcr>
><dispexe num=6 alt=""><tcr>
><dispexe num=7 alt=""><tcr>
></region>
>
>When the user compiles and runs this shell, pressing more will simply
>increment each dispexe by 7. So it becomes programs 8-14. Just as in
>ZShell. =)
>
>Future versions of the shell compiler should include:
>
>- bitmap and ZCP graphics
>- shutdown text
>- key-defines (IE pressing F1 brings up an About dialog)
>- point-n-click capabilities
>
>I leave it up to the compiler-designer to implement these ideas as s/he
>sees fit.
>
>Comments?
>
>--Matt Cooper / mnemonicdevice@hotmail.com
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
Follow-Ups: