= TextTools Workshop = == on texttools interface concepts == Latest change: Thu Oct 23 16:45:08 CEST 2008 this page: http://www.guckes.net/vortraege/abstract.workshop_texttools.txt author: Sven Guckes ($BIO) === Presentation+Feedback $ZEIT $ORT $TINYURL $TITEL $UNTERTITEL Feedback bitte an Sven Guckes workshop-texttools(at)guckes(dot)net TODO... === abstract - really short! texttools user interfaces (TUIs) already have a lot of cool ideas. i would like to show you some nice examples. hopefully this talk can motivate more programmers and users to include them in other programs - whether in TUIs or GUIs. the goal is to advance the interfaces of programs with more of the already *existing* features by giving the user more commands and options to enable a more powerful tool for speedier action. in essence: make programs more powerful -> save time! === abstract Almost every interactive program offers another kind of interface. Some of these you can see in almost every program: dialogs with many buttons, prompts for texts, menus and submenus - some with keyboard shortcuts for commands. However, some of them seem to be quite seldom, eg internals command lines, and fast switches. This is a (small, well, growing) overview to some of these ideas, both with a description and example, either as text or as a screenshot. And then some more. Some ideas on interfaces are mostly to be applied for programs running in terminals. this is why I call them "texttools" - in contrast to "graphical tools". Texttools usually are perceived as outdated programs because of their text interface. But I claim that these tools are here to stay with us for a very long time, if not forever! Hopefully these ideas will be implemented with more programs - texttools or gui. Mind you: This is not about any special programming language. This is about *concepts*! =================================================================== === Texttools "Texttools are here to stay!" why? simply because they have a very low overhead (no pics, see?). they appear on small display (cellphones, palms, watches) and on small systems (embedded computers, old PCs, teletypes on supermarket cash desks). the further a computer is away the lower bandwidth may be available, making it impossible to operate it on a full graphical display. so remote computers are mostly accessed via text only. Application o gadgets will have embedded processors - and some will be equipped with a display Cell p (think cellphones). Compression: text usually is based on letters which take only a part of all available characters. therefore text compresses well. and this is good for use on small lines like modem lines. Automization: texttools can also be used easily for automization (scripts). shells and other texttools like perl can run scripts. and... more. but this would be a talk on its own. there are a lot of reasons why i like these programs. i do most of my work on a text interface. i find them fast, and there is less fancy stuff to distract me. ;-) === Startup startup options change the way the programs work by changing the default values. short option names are usually "-x". example: ls -l long option names. some programs have a *lot* of options names. example: gpg two long option names which every program should have: "--help" for info on startup option and "--version" for info on release date and version, author, home site. === setup files standard files and directory names: /etc/{$PROGRAM}rc /etc/{$PROGRAM}/ $HOME/.{$PROGRAM}rc $HOME/.{$PROGRAM}/ "rc" stands for "read/run commands". some programs allow the configuration file to be defined by an environment variable: . examples: BC_ENV_ARGS=$HOME/.bcrc COLORTERM=yes # mutt GZIP=-v9 IRCNAME='Sven Guckes (0x57F77F09)' LESS=aCMsei LS_COLORS=... WORDCHARS='*?_-.[]~=/&;!#$%^(){}<>:\'' # bash+zsh BROWSER EDITOR TIMESERVER VISUAL === SetupFiles remember: setup files are text, too. just like scripts. they can be read with almost any text viewer, printed, and edited with any text editor. setup files with their own format usually require a special program to view and edit. more problems! Long options names allow lookup. However, they usually provide TODO: sites with setup files. eg dotfiles.com === splitting setup files - source one setup file is enough for every program? NOT! example: mutt + muttng ~/.muttngrc: source ~/.muttrc mutt also has "backtick evaluation": so - when "script" yields a filename then you can use it like this: source `script` lib "confuse" -> Martin Sander === Abbreviations and Prefix Expansion Many applications include a way of "editing" text - especially when there is only a short text to enter. Mostly there is some kind of input line which should not be mixed up with a command line as a command line usually offers a LOT more commands for jumping around and change text, eg delete complete words. A feature that is almost alway missing is "abbreviations". You simply cannot enter a word which gets expanded automatically. Counterexample: The IRC client "irssi" allows abbreviations. Once you finish typing s word by typing a non-letter the word is expanded. However, before you use an abbreviation you have to define it first. Adding many abbreviations is quite time-consuming. this is where prefix expansion comes it. You type the start (prefix) of a word - and a command will search backward in the previous text to find possible expansions. This way you would type a long word only once - and then use prefix expansion to expand prefixes. The good editors have these features, of course! Why not add these to smaller texttools? === Mouse Support - gpm Some programs support mouse clicks on terminals via "gpm". Example: elinks + links === Fast Switches idea: type an option name, ie the minus key, then followed by a letter - and this switches the option as if you supplied its name at startup as an option. example: less === Color color selector. problem: the "color wheel" is "protected" by a patent. standalone color selector - none?! === Percentage Indicator When looking at some text which does not fit on the current screen eg with a "pager" ("less", "more", "most") then the program will display a "percentage indicator" Example: less, vim. === Format Converters So many formats - so little converters. SGML -> LaTeX -> PDF -> HTML -> text/plain TODO: Werner Heuser - website on conversion tools === Special Lines == Command Line ...... == Input Line ... == Identification Line nano: "GNU nano 1.3.4 ... New Buffer" "GNU nano 1.3.4 ... File: $FILENAME" slrn: slrn 0.9.8.1pl1 ** Press '?' for help, 'q' to quit. ** Server: news.vr.in-berlin.de == Messages Line nano: "[ News File ]" == Help Line mutt: q:Quit d:Del u:Undel s:Save m:Mail r:Reply g:Group ?:Help nano: ^G Get Help ^O WriteOut ^R Read File ^Y Prev Page ^K Cut Text ^C Cur Pos ^X Exit ^J Justify ^W Where Is ^V Next Page ^U UnCut Txt ^T To Spell slrn: spc:Select p:Post c:Catch-Up l:List q:Quit ^r:Redraw (u)s:(Un)Subscribe === Text Editing === Commandline Example: mutt vim === Prompts nn: list of possible command keys. example: "what now? (abcdeABCDE234)" === Menus and Submenus links: File View Link Tools Setup Help extra color for direct key: nice! jumps: first+last item, middle item search by keyword meta example: mutt +-------------------------------+ | Open new window | | Open new tab t | | Open new tab in background | | Go to URL g | | Go back Left | | Go forward u | | History >> | | Unhistory >> | |-------------------------------| | Save as | | Save URL as | | Save formatted document | | Bookmark document a | |-------------------------------| | Kill background connections | | Flush all caches | | Resource info | |-------------------------------| | OS shell | |-------------------------------| | Exit q | +-------------------------------+ however, blind people cannot make use of the extra color. however, someone just *might* add some support for recognition! jed: F10 key ==> File Edit Search Buffers Windows System Help indicates the use of the F10 key to access the top level menu - nice! submenu indication: ">>" shortcut indication to the end of line. jed also keep the latest context within submenus. ascii borders vs special character borders -> centericq -a === Keybinding === Dialogs elinks: many dialogs, menus+submenus, options dialog. some dialogs are too big for a small display (think cellphones here, or BIOSes, or console). a text interface can be designed to be small. === Help System vim: :help navigation textutal links display of help pages and manuals -> context help by message line. missing setup file -> newbie mode. === Search for Substrings extract all filenames based on a substring search. direct start: possibly too many matches. variant: start after input of N characters. eg after two characters. example -> Finder application. carsten ... more interesting: search the *meta* info to files, too! might require a special file system. === KeyBindings defaults.. unchanging ones: ? for help CTRL-G or ESC for abort CTRL-H (BS) for return (by one level) CTRL-I (TAB) to advance to next button or input field === Frontends Padrones MUD frontend (PMF) mldonkey - several frontends k3b - frontend for cdrdao, cdrecord, cdr-tools, dvdrw-tools, mkisofs or growisofs... dvd::rip - frontend for transcode+codecs abcde - frontend for lame, id3tag, cdparanoia.. gmplayer - frontend for mplayer === Progress Bars "[ ... NN% ... ]" the idea of a progress bar background color fills up bracketed are in inverse color (bloody patent!) === Screen Info when something is wrong then the context is often unclear. therefore it is a good idea to add info on the current context onto the screen. top line: program name, version number, menu name example: Bark 0.23 [2006-12-02] on Linux - Folder Index - $MAIL === History mutt and vim both offer histories on several contexts. mutt: histories for commands, limit patterns. vim: histories for commands, search strings. === Sessions Files === Save Current State vim: :options === Options Menu elinks. always opens a huge dialog box. current values are *not* being shows. you *must* open a dialog to see the current value - so you cannot see a color combination together. you always have to enter a digit - even for on/off switches. a value of "1 " (space after the digit) gives you an error ("Bad option value."). there is no popup menu for list with given values; you *must* know valid values to enter them manually (eg Language). there is *no* search command to find an entry in submenus. a command line sometimes would be a LOT better here. === Credits Thanks to all programmers who have written the tools which i use on a daily basis - and to all who are supporting them throughout the years of development! just to mention a few: elm irssi less links mutt nano nn screen sed slrn vim wget zsh === Feedback Are there any typos? Is anything unclear? Do you like the ideas? Do you have more to add? then please contact me at texttools(at)guckes.net! thanks! === Links This document is available at http://www.guckes.net/talks/abstract.texttool_interfaces.txt === Bio Sven Guckes, *1967, studied maths+compsci at the Free University Berlin. He supports Free Software, has talked at several events in AT+DE+NL. Texttools geek, freelancer, lives in Berlin - where else? ;) ========================================================== === META Integration -> Killer Application? or combination - using eg "screen". === NEWS! so.. what hasn't been done yet? basically, an application which combines several of the already known features. so - build an application "just because"? no! === Future Projects SO = set organizer tag object with set name order them apply bool operators could become an organizer or PIM STFL - Structured Terminal Forms Language/Library http://www.clifford.at/stfl/ show all input from keyboard within application. this can be used in documenting its use when "filmed". ==== TODO: HTMLize add screenshots in color how shall a setup file look like? Nils Magnus standard on *.ini files : key=value - insufficient "eigentlich will man XML!" Andreas Kupfer EOF