[270] in Athena User Interface
Current thinking on gZephyr
daemon@ATHENA.MIT.EDU (Christopher D. Beland)
Mon Jul 10 09:00:44 2000
Message-Id: <200007101300.JAA01884@No-Whammies.mit.edu>
To: aui@MIT.EDU
Date: Mon, 10 Jul 2000 09:00:36 -0400
From: "Christopher D. Beland" <beland@MIT.EDU>
So Ariel and I spent a lot of time end of last week talking about how
gZephyr should look from a UI perpective, and about what sort of
functionality it should provide. What follows is a written summary of
our discussion, combined with my core dump of all the zephyr-related
information I've accumulated to date.
Feel free to comment if you have feelings one way or the other about
this sort of thing. 8)
-B.
------- Forwareded Message
Date: Fri, 07 Jul 2000 06:55:16 -0400
From: "Christopher D. Beland" <beland>
To: ariels
Subject: gZephyr
So I tried to encapsulate our discussion in writing so that a.) we
don't forget useful things b.) other aui types can comment on it, and
c.) I can post it in the project notebook. I also did a core dump of
any other suggestions or fact I had accumulated in my previous
research. Do what with them as you will. 8)
The potential feature list is frighteningly long. Let me know if this
is close to what you are envisioning or not; feel free to edit it and
send it back or whatver. WHo knows how much of this we'll actually
ever get to.
-B.
Introduction
This file describes our current thinking on how gzephyr should work,
from a UI perspective. It's organized in order of increasing
functionality, which might very well be how it is implemented.
We might use calls to zwgc, zctl, zwrite, etc. commands during
prototyping until libzephyr calls can be set up properly.
* SEND-ONLY:
---------------------------------------------------------
gZephyr: Send
[Send to user] [Send to class] [Send to instance]
_______________
Class Instance | |
| tibbetts |
message white-magic | yak |
_____________ | ariels |
| beland |
| |
Message: | (capable |
| of multi- |
[fill-in box] | column |
| layout) |
|_______________|
---------------------------------------------------------
Functionality:
When user clicks on "send to user" then "username" appears instead of
"class" and "instance", and the user may specify the person to send
to.
When user clicks on "send to class" then they are able to fill in both
"class" and "instance (optional)". A blank instance defaults to
"personal."
When user clicks on "send to instance" then "class" is set to
"message" (which cannot be modified) and they are allowed to specify
an instance. (An error diaglog appears if no instance is specified.
Sending to message,personal,* is not allowed because it interacts
badly with old dotfiles.)
Clicking on a person in the list on the right sends to that user.
CTRL-clicking can send to multiple people.
A class/instance window, not unlike the user window, also exists.
Whenever you send to a class/instance, that class/instance gets added
and is displayed as "classname, instancename".
Right-click on a user should zlocate. (HOTD!)
User list is maintained in .anyone for backward-compatibility, and
ignores lines beginning with # or !.
Sends should get confirmation back, like zwrite does.
* SUBSCRIPTION MANAGEMENT
---------------------------------------------------------
gZephyr: Subscription Management
( --pulldown menu-- )
CURRENTLY SHOWING: (Current subscriptions )
(Default subscriptions )
(Subs for group: "punt")
(Subs for group: "tool")
(X) Subscribe to personal zephyrs
(X) Log personal zephyrs to files Classes
___________
Class: sipb | message |
| geek |
(X) Subscribed | greed |
(X) Log to file | sipb |
| 6.001 |
(X) Instances are important | |
| |
Instance Settings | |
| |
linux subscribed | |
linux.d subscribed | |
latex subscribed | |
food ignore | |
* ignore |___________|
[Add/sub instance... ] [Add/sub class... ]
[Del/unsub instance...] [Del/unsub class...]
[Reset to system default]
-----
Notes: The recipient part of the triple is generally ignored, since
people who mess around with that sort of thing are very advanced
users. But, we could add an "advanced" screen that allowed people to
sub/send to arbitrary triples.
"Groups" are files named "~/.zephyr.subs.groupname" and the default
group is ~/.zephyr.subs, so as to be backwards-compatible.
Add/delete dialog:
---------------------------------
Class: sipb (filled in on open)
----------
Instance: latex.d
----------
[Subscribe for this login only]
[Add to default subscriptions ]
Add to group: (--pulldown--)
[Add new group]
Delete group: (pulldown)
---------------------------------------------------------
Basic misc. operations
- Flush locations and unhide
- Setting exposure level
Exposure settings should be:
- Announce login/out to other users? (checkbox)
- Visible: nowhere - inside athena.mit.edu only - everywhere
(Radio buttons, nowhere grays out if announced is checked, bumps
you up to athena-wide if necc.)
- Hide temporarily
- Unhide temporarily
- Kill zephyr entirely
- Set/unset zaway (pointer to hand-editing .away file)
One cannot unsubscribe from systems zephyrs (i.e. subs to filsys and
operations) without manually using zctl.
System defaults:
- Subs set by zinit (filsys, operations)
- message,personal,%me%
- help,*,* (listed, not subbed)
* RECIEVING ZEPHYRS
So far, we've come up with three basic display methods:
1. zwgc-style popup, one window per zephyr.
2. AOL-IM style, one window per user, class, or instance.
3. xchat-style, one window-tab per conversation
It would be ideal to support all three, and allow users to choose
between them.
Option 1 necessitates use of the "sender" and associated xzul-like
user list described above. With 3, the sender is simply expanded to
include a series of windows for receiving incoming zephyrs and
denoting outgoing ones, accessible by click on tabs. For 2, a "send"
area could automatically appear at the bottom of each window for an
immediate reply, or a universal "sender" could be used for all
conversations. The central sender could be directed by clicking on a
button on the appropriate converastion window, or by specifying
classs, instance, user, etc.
Note that on some classes, instances are irrelevant, whereas on
others, they contain entirely separate conversations. Whether or not
to create a new window/tab is decided with the help of a per-class
boolean value that the user sets for this purpose.
Receiving preferences
- Display mail notification zephyrs?
- Option to receive popup notifications of logins/outs.
- Display pings?
- Style to display output in (see samples in
/mit/aui/evaluation/gzephyr-samples.txt)
- Make window timeout?
- Make pings timeout or get replaced by the next zephyr from that
person?
- Implement minTimeToLive?
Notes
- message,urgent,%me% is not in the default subscriptions; we don't
support it.
* GLOBAL PREFERENCES
- Prefix for log files (for which a different one is written for each
class, instance if "instances important" bit is set, and user.
- Prefix for files in group lists
- Whether to popup a new window for each message, create windows in
tabs, create new window for each "channel" (person, class, or
instance), or ask every time a zephyr is received on a new
"channel" (maybe specify in advance)
- Pointer to hand-editing .zwgc.desc
- Color and placement of zwgc popups on various "channels" - maybe
just a pointer to hand-editing Xresources at first.
- Set tty fallback mode true/false (deafult true)
- Zephyr authentically? (default yes)
- Expand tabs into spaces? (deafult yes)
- Auto-zping?
- Auto-clear on send?
* ADDITIONAL FEATURES:
- In send window: Zephyr-ping a user
- In send window: Zlocate a user
- Support to run an arbitrary command to get zsig
- Built-in zsig randomizer or sequencer support
- Interrealm zephyr support (accomplishable by specifying *@realm or
username@realm on "advanced" screen)
- With zwgc popup style, hitting "p" on a window makes all current
and future windows on that "channel" appear in that location.
- Ability to ignore instances, ala zpunt (negative subs)
- Ability to ignore other choice users
- Sending personal zephyrs to multiple users (ctrl-click on user
list) - with/without cc: line
- Able to set tty name (shows up in zlocate)
- Handle embedded URLs
- GUI support for color, different fonts, etc.
- Sending pictures, sounds, etc., over zephyr is probably a Bad Idea.
- Button to goto print config from zephyr config (if needed)
- History of recent sends you can scroll back
- zcrypt support
* RARELY USED FEATURES
- Specify opcode
- Flush ZHM state
- Find a new zephyr server
- zstat
* REFERENCE SECTION
How to detect various types of zephyrs
Pings
- opcode "ping"
Zaway
- no opcode
- Sig: "Automated reply:"
Login/out
- class login
- instance username@realm
- opcode USER_LOGIN or USER_LOGOUT
Print jobs
- sent to message,personal,%me%
- no opcode set
- Sig: printername
- From: root@printservername.mit.edu
- OLC Answer: Go to printer config to turn these on/off!
Loggers
- You can set the opcode "nolog" and some zloggers will respect it,
this does not include the Ops logger that follows -c help and -c
message (/mit/zlogs or /mit/zlog). The SIPB logger (/mit/sipbzlog/)
respects this only on some classes.
Zephyrbots
- May set random or no opcode
New mail notifications
- As of July, po7-po11 send zephyrs to -c mail -i pop (via
zpopnotify) with the body "You have new mail." If the user has
uncommented certain lines in ~/.zwgc.desc, they send (via
zmailnotify) ro -c mail -i popret with the opcode NEW_MAIL, with
select mail headers in the body.
- For po12 and above, subscribe to -c mail -i *, and the servers will
send to -c mail -i IMAP_FOLDER_NAME where the folder name is
usually INBOX. They send from, for example:
imap.po12@po12.mit.edu, and with an empty opcode.
- Beland e-mailed the postmasters to see if this is changing anytime
soon (presumably to all-IMAP).
