[275] in Athena User Interface
Re: Current thinking on gZephyr
daemon@ATHENA.MIT.EDU (Richard Tibbetts)
Tue Jul 11 00:04:45 2000
Message-Id: <200007110404.AAA26086@hikari-no-ken.mit.edu>
To: "Christopher D. Beland" <beland@MIT.EDU>
cc: aui@MIT.EDU, tibbetts@MIT.EDU
In-reply-to: Your message of "Mon, 10 Jul 2000 09:00:36 EDT."
<200007101300.JAA01884@No-Whammies.mit.edu>
Date: Tue, 11 Jul 2000 00:04:39 -0400
From: Richard Tibbetts <tibbetts@MIT.EDU>
Though I have comments on specific details of this doc, I think that
there is too much here to respond point by point. Thus I will just
give a couple of high level comments.
This is (I hope) only a brainstorm, not a technical spec. Looking
through it I see a lot of the same things I have heard when talking to
people about thei own ideal zephyr client. Some of them are good
ideas, and some of them are not. I do not think that implementing yet
another zephyr client is the goal here.
We want to come up with a well done, client that replaces zwrite, zctl
and znol. We do not need to replace zwgc. We certainly do not want to
replace vt. And we are not going to attempt to do social engineering
or provide significant extra functionality until the basic stuff is
there. We have more important things to do.
I am mostly writing this for the benefit of those watching. I believe
that Ariel understands the priorities here. The most important thing
is that at the end we actually have a zephyr client and not a failed
second-system.
tibbetts
On 7/10 "Christopher D. Beland" <beland@MIT.EDU> wrote:
>
> 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).
-*- http://www.mit.edu/~tibbetts -*- finger tibbetts@monk.mit.edu -*-
