| From: | Marek Stepan |
| Date: | 20 Sep 2000 at 08:30:45 |
| Subject: | AMIOPEN: AMIOPEN: GUISHORTCUTS,AMIPAK,FILESYSTEM,BALANCING |
Hi !
I'm newbie in this list, and I have some comments :
* CONFIGUR. SHORTKEYS/CUTS
1) Lets start talking about something "completly different".
bash,csh,ksh... can be exactly same programs in TAO, if you
use launcher_tool (for starting programs) and console_output
(for visualising outputs from stdout, stderr.) Only diference
is used DIALECT which is used to force application bash,csh...
to do, what user need. So one binary, and lot of ascii.config
which describes other DIALECTS (do I say REBOL?) [1]
2) So If we can create programs "so easy", for TEXT_EDITOR
we need 2 components : BUFER_tool and EDIT_TEXT_WIDGET .
We expect that a) "BUFFER_TOOL" is capable of loading-in and
save-out ANY data from/disk/net... b) EDIT_TEXT_WIDGET
is capable of editing text. So config will be like :
text_editor_apilc.conf
APPLICATION_NAME : TEXT_EDITOR
TOOLS :=( BUFFER_TOOL , EDIT_WIDGET )
OPTIONS : BUFFER_TOOL : USE_TEXT_DATA_ONLY
OPTIONS : EDIT_WIDGET : USE_TEXT_DATA_ONLY
3) We have applic. which WORKS, but we are USER-INTERFACE
designers, and we want to have EDITOR which work EXACTLY
as EMACS or VI. So we need to define MODUS_OPERANDI :
vi.config :
MODUS_OPERANDI:=(TEXT_MODE,COMMAND_MODE)
MODUS_OPERANDI_SHIFT:= key(ESC)
emacs.config :
MODUS_OPERANDI:=(TEXT_MODE,COMMAND_MODE)
MODUS_OPERANDI_KVALIFIER:= key(CTRL+ALT)
{Everybody knows, that inside VI ESC switch between COMMAND_MODE
and TEXT_MODE. EMACS : both modes works together, and COMMAND_MODE
is reached if CTRL+ALT .... }
In COMMAND_MODE we expact that application is capable of
loading/saving any data-buffers in memory, as we want to
edit simultanously. TEXT_MODE : guess what. [3]
4) So new program is created, and now we want to use
those SHORTCUTS/SHORTKEYS... (of course localized)
AND we can define :
buffer_tool.cfg
ALT+O: Open_File "Data offnen"
ALT+S: Save_file "Data speichern"
text_edit_widget.cfg
ALT+A: Select_all "Selektiere alle"
ALT+O: overwrite_mode "wiederschreibbar modus"
As you can see, EVERY file req. in EVERY single applic. will
use OUR CUSTOMIZED localized shortkeys. And what happen if two same
exists : ??? THIS IS EASY !!! Do you remember vi.config
and emacs.config ??? If I press ESC I switch appl. modus
to TEXT|COMMAND_MODE and ALT+O is EXACTLY defined. If I use
emacs.config PARALEL_KVANTIFIER is used, and due to fact, that
SHORTKEYS are searched continuously, and first match is used
{MODUS_OPERANDI is list with TEXT_MODE, and than COMAND_MODE,
so it means that first text_mode.cfg is processed, and
OVERVRITE_MODE is selected. } [4]
5) Lets'talk about ALT+F4.
This is config for component/tool "basic_graphics_window".
Because every X-server/applik will contain this component
It will be nice, if some default.basic_gui_window.cfg"
will be used, if my_applik.cfg doesn't redefine ALT+F4
for something different, let say applic. NORTONCOMMANDER .....
6) If we talk about COMAND_LINE_PROGRAMS, using "?"
(amigaClassic) was BEST idea. I know two AmigaClassic
programs, which builds GUI only from "?".
amipak.conf
MODUS_OPERANDI:=(ADD2ARCHIV=getopt("ADD"),DELETEFROMARCHIV=getopt("DEL"))
If you compare vi.cong and amipak.conf only diference between
is, that amipak is NOW shell command only, because MODUS
is taken from CLI only. Imagine possibility, if config file
describes KEYs ? yes, that modification and using "basic_graphics_window".
will be only diference between full GUI and CLI aplik.
7) Games : can have GUI interface too ;)
MODUS_OPERANDI:=(INTRO,LEVELX,GREETINGS;DEMO)
Some sort of timeout, for default DEMO ?action can be used.
Lets summarize this crazy idea :
application = some basic tools/components + lot of ascii config.
ascii config can be written in XML .... and so on, but we are
sure, that contens of this ascii file, will be some GUI-DIALECT
talking about DIALECTs is boring, let ask somebody about
support for LISP !! yes ! hey ! I'm not crazy !
LISP is powerfull when we need to preprocess lot of human-readable
text files ! Do you know, operating system which requires 8 MB RAM
and continuously Swapping ? {hint EMACS ;)}
TA0 is "sort of INTERPRETED system", and LIST is interpreted too.
Reason, why is EMACS bloated is, that LISP is converted to C, because
no fast interpreter before Tao exist. And last not least LISP
ideas are very simmilar with REBOL.
If you thinks, how to COMMAND, CONTROL and CONQUER ;)
your DIGITA_DEVICE based on AMI/Ta0, Logical question arise, I.E.
which and how many CONTROL PADS/KEYS... to use. If you have
JOYSTICK, for GAME, user expect, that " SOME PRESSED KEY change
game internal_status_operandi from INTRO to LEVELX , if user
starts AMIPACK he wants with JOYSTICK switching from
mode ADD2ARCHIV to DELETEFROMARCHIV andso on. This is perfect
example of FINITE-STATE-MACHINE, and ALL possible WAYS from/to
other STATE are defined (see aplic.conf). If USER wants "Voice control"
IT CAN BE EASY IMPLEMENTED, EVEN FOR PALM PILOT DEVICES,
BECAUSE YOU HAVE VERY SMALL DICTIONARY OF POSSIBLE COMMANDS !!
For AmiPACK you need to disting. between ADD and DELETE which
is easy. With this aproach, you DOES'T CARE, HOW MANY KEYS
your DIGITAL_DEVICE HAVE, because you are using few-state
flowchart for 99%time. Only in very rare cases, you needs to
have full keyboard, but only for cases as TEXT_EDIT_WIDGET
and for this cases, you can use EMULATOR (remember coin-up
machines, and how to write your name in HI-SCORE with JoyPAD ???)
Don't forgot all those weird input devices, HALF-SIZED keyboards,
50button joysticks, Gloves .... all must be capable control
my DIGITAL_DEVICE . It can be something like INPUT_DEVICE_DEMON,
which reads, that current aplication have TEXT_MODE and COMAND_MODE,
looks for my_forcefeedback_joystick.cfg reads, that this HW have
20 digital buttons, 1 analog control and vibration feedback.
third file will be my_forcefeedback_apic.cfg which will define
that RED button is COMAND_MODE , GREEN is TEXT_MODE and so on.
This file can be GENERATED AUTOMATICLY FOR ALL POSSIBLE CASES !!
IF number of available buttons is biger then 2 (3).
{NEXT,ACCEPT,(CANCEL)}
Those weird input device needs UNIFORM configuration file !!!
Main idea for this, was possibility to CONTROL with AREXX program
EVERY application and possibility to create new one. But with this
approach is AREXX redundant -> user simply "create" new
applic. "on the fly" with some RESOURCE_FORK_EDITOR.
Comments :
[1] Idea is, that with using launcher_tool + console_out_tool +
+ rebol_tool + ASCII>CONFIGURATION I can create lot of
new application. (ie. bash,ash,ksh,csh....)
[2] using STANDART Tao components everyone can create "new" app.
[3] every appl. can reuse standart "tools"-components.
[4] finally, those stupid ALT+F ... and so on are defined.
* LOADING/BALANCING :
Is bad question, IMHO better is to ask somebody about ability
to RESTART or FROZE running applik./tool. I mean, that if I start
RAYTRACER, or some heavy_number_cruncher, it will be nice
to have possibility to DUMP current running application to disk
or to other media. If I start raytracer, and after 2hours
I insert SECOND CPU I need ;), that raytracer_applik must be capable of
RESTARTING, and I KNOW, that Ta0 dynamic loader is capable
of using best suited CPU for my applic, so I'll pay only
time required for applik. RESTART. Adding MULTIPROCESOR
capabilities is 80% task for Tao loader, and 20% problem
if TWO EXACTLY SAME applik. can COEXISTS in RAM, and
how will communicate together, i.e. wait for AMITWO.
second example is, If I need to start second number_cruncher,
or turn my computer off, ability to DUMP running applic.
will be WERY USEFUL ;)
* FILESYSTEM :
Nobody talks about, but using stupid POSIX : ZIP,TAR programs is
IMHO BAD idea.I would prefer to have 3 data category :
a) user_created_data
b) converted_data/cached_data
c) system/program data
system/program/data are easy to explain, WINDOWS/* directory ;')
Why user needs to see those data ???? Those data must be hiden
to BFU, and only INTSTALL_MODE or ROOT_MODE will show those.
user_created_data - those data are most important ones ;)
At all costs most be protected ;)
converted_data,cached_data - are all those, whose are created
FROM "user_created_data" . It would be nice, if MY_LOVE_LETTER.PS
will be only few bytes short, with
config : "LATEX MY_LOVE_LETTER.TEX | DVIPS -T A4 "
If you have lot of space on disk, you can create BIG postscript file.
If not, few bytes have same information ! And this is keypoint.
Similary, if you create Thumbails, previews for pictures...a.s.on.
This works for EVERY user_created_data ! Last example :
You have my_program_source.c , and only difference between
my_program is my_program_source.config WHICH describes ONE
WAY options for GNU compiler.
If you KNOW, which data are IMPORTANT, and whose NOT, you can
use CONTROL REVISION SYSTEM and BACKUPs only for IMPORTANT
data, and you don't have filesystem overhead.
O.K. Last example for FILESYSTEM. Some peaple thinks, that
FOLDERS/DIRECTORYS are important. Those people ARE WRONG !!!
If I have hudge collection of JPG pictures, most people
use FOLDERS/DIRECTORIES as sorting category for those pictures !!!
NATURAL/HUMAN filesystem, uses ONE place to store user_created_data
which are accesible by using sorting options.
If I search for something, I use
cd PICTURES ; cd WOMAN ; cd PAMELA ; show * ;)
IMHO future IS, that one picture is accesible in many folders,
PICTURES/WOMAN/PAMELA/pic1.jpg ... and
PICTURES/BACKGROUNDS/800x600/pic1.jpg
DATA and FILECOMMENTS/LABELS are both important, filesystem must
be micro_SQL ;) based ;)
*AMIPAK
Please ! add ability to STORE FILE in archiv WITH SAME NAME
and/or SAME CRC !!!!
* If you can store two same files with same name, you have CVS or RCS !!!
* If you can store two exactly same files, you have perfect
mechanism agains archiv coruption !!! (If one file is corrupted,
second may not!)
*EMAIL-DISCUSSION
;) It's lot of traffic here, I personaly had about x emails per month,
and email-reading is very time-consuming job.
1) How about WEEK-DIGEST ??? www.onelist.com makes it, and I think
others too. It is ONE EMAIL per week, which contains ALL emails,
and TRAFIC is low ! If DIGEST is THEN sorted BY SUBJECT, it
would be SUPERB !!
2) How about ARCHIV/FAQ ???
I think that traffic will be very high, after release of Wir99/NT tAo,
and Solving this problem, will be very helpful. IMHO I don't like
if best guys, let's say from AI, are spending time ansfering
boring emails ;) (as this is), It can be accepted, only if
requests/questions ... are highly organized. AI have listserver,
and if all people uses siple rules, it will be helpful !!
Lets show example :
I nead to ask AI about something . So I send Email with text :
!ASKAMI
Hi garry, how do you do ?
And I have some suggestion, about something, which I wont to implemet
in AmiOneO.S.
!SUGAMI
Please implement true realtime multitasking !
If every month simple FAQ and list of commands will be posted,
It is guarranteed, THAT :
* Suggestions from "developers/users" will be 99% DELIVERED
to RIGHT PERSON
* Suggestions for FUTURE ENHANCEMENTS can be archived,
* Discused SUBJECT can be 100% ACCURATE !!!
* Answers can be sorted/organized too !
Idea is, reduce time overhead for HIGH PAYED people.
{Some people pays with FREE TIME, which is sometime more expensive.}
I think, that implementing such feature with REBOL will be few bytes
of REBOL code.
[I mean, sorting by index, sorting by command, remove redundant text .....]
Thanks for reading,Sorry for my terrible English,and have a nice day.
POSIX/*NIX is bad, long live for Ami !
Don't waste time with odd and ugly *NIX software.
Why to PORT awk when REBOL is aviabile ? and so on. Write DIALECT not code !
Subscribe/Unsubscribe: open-request@amiga.com
Amiga FAQ: http://www.amiga.com/faq.html