//////////////////////////////////////////////////////////////////////

* Short-term TODO: Pan (0.8.0?) (Tuesday, March 7, 2000)

[Charles]
[ ] WRITE A GNKSA SUBMISSION DAMMIT
[ ] dogfood: author to lhs of date in article list.
[ ] dogfood: paste doesn't work in compose window?
[ ] dogfood: pageup/pagedown in text bound to some key for parent/child nav.
[ ] dogfood: a third layout mode.
[ ] dogfood: cron-able app to d/l new headers, optionally bodies, in non-gui.
[ ] wendell: multipart decode holds too many parts
[ ] pan-users: online/offline support (don't kill existing processes)
[ ] pan-users: instead of unread, unread/total in alist column
[ ] pan-users: download selected bodies
[ ] pan-users: prefs option to limit all total server connections
[ ] pan-users: prefs option to automatically load new headers on entering group
[ ] pan-users: status bar for "no new headers" "message sent successfully!" etc
[ ] usability: if it's a multipart, default action is...?

[Jason]
[ ] User Folders, hooray!
[ ] binary retrieval druid (wizard like for automatic binary "sucking")
[~] Add "Show Groups" pullout menu into Groups menu, make sure to sync
    with the optionmenu on the toolbar (and set the grouplist column
    title)
[ ] Make left and right arrow keys do expand/close in articlelist
    (Should overide/remove default Gtk bindings for those first)
[ ] Import/export of subscribed groups
[ ] Reorganize preferences.
[ ] Reorganize menus.

[Matt]
[ ] zag's plug-in-an-editor RFE

[Unclaimed]
[ ] Matt, want to do a queue manager for 0.8.0?

//////////////////////////////////////////////////////////////////////

[Unclaimed]
[ ] "Wrap Text" option
[ ] xnews-like text toolbar
[ ] Queue Manager
[ ] Filter to pass messages through before they're posted.
[ ] shortcut to "get new articles"
[ ] message-window should use the user prefs on which headers get shown.  IMHO
    this should be done by making Message enough article_data like that it can
    call gui_set_headers_default() to build the headers GtkTable.
[ ] I18N encoding of header information -- rfc 1342
    http://andrew2.andrew.cmu.edu/rfc/rfc1342.html
[ ] Ctrl-F doesn't pop up the find dialog?
[ ] DMACon: Default to fixed width fonts in read/compose
[ ] DMACon: paragraph word wrap command
[ ] DMACon: auto-delete signature when replying
[ ] http://www.debian.org/Bugs/db/50/50897.html
[ ] stop all
[ ] put server selection into the menus
[ ] prefs option to check server for new messages when you load a group
[ ] gnksa 7e
[ ] gnksa 12c -- we may not want to do this
[ ] gnksa 13a
[ ] gnksa 13b
[ ] gnksa 13c
[ ] gnksa 13d
[ ] gnksa 14d
[ ] more search options to "find" dialog? -- filter by date
[ ] log viewer improvements: coloring based on priority, error, etc
[ ] queue manager
[ ] per-group configuration options: logging
[ ] ability to attach files to posts.
[ ] add "Delete Attachment" popup, that when clicked deletes the decoded
    article from the download dir (if it's still there), and cached
    headers/bodies.
[ ] group-centric design?
[ ] .newsrc support
[ ] URL grabbing (from message bodies), see gaim's conversation.c
    (linkify_text()) for examples/more detail.

//////////////////////////////////////////////////////////////////////

* Long-term TODO: Pan 1.0

** Printing support.

   Obviously most good programs should have a way to print out some form of
   output.  It would be great to have the ability to print messages or even
   things like group lists or log viewer information, hell, anything.  We're
   kind of depending on the gnome-print module from the GNOME Hackers to
   develop further, with some good API documentation and full functionality

** Internationalization (i18n).

   Pan already has the basics of i18n down, and I'm not sure what else really
   needs to be done besides testing and more translating.  But, just to make
   it a known item for version 1.0, I think that by version 1.0 we should
   have Pan 100% translated into at least 12 languages and have tested each of
   these languages to be sure the translations work and are full.
      
** Posting attachments.

   Although it's not heavily used, obviously less than downloading
   attachments and less than people reading actual messages, version 1.0
   should have the ability to post attachments, with other added goodies
   such as automatic splitting of large files into multiple messages and
   such.  We might be able to borrow some attachment code from other
   mailer programs like mutt, pine, or spruce.

** Full customization.

   With this, I mean what we're now approaching in 0.6.3.  The ability
   to set fonts, colors, and almost everything else.  We need to keep
   developing the two layouts, paned and notebook, so that users can
   choose between their favorite style.

** Download manager.

   For some silly reason, I think this would be the absolute coolest
   feature for a news reader specializing in binary retrieval.  I
   visualize a kind of getright-like download manager that allows you to
   stock up a big list of downloads, save the list, change their order,
   process more than one at a time, "resume" (if there is such a thing on
   NNTP), and such.  If/when the ability to do inline images comes, then
   we could integrate an image viewer into this part of the
   program... you can hopefully see how cool this would be.

** Drag-and-drop.

   Your thinking, what the hell?  Yeah, we should have some drag-and-drop
   functionality too.  I can only really think of this applying to the
   posts with binary attachments, such as dragging a post from the
   article list to gmc or the desktop and having it do the
   download-decode-save to that location or something.  We'll look for
   more ways to do this.

** Minimal HTML support/recognition.

   I'm not talking coding mozilla here, but like, if a message has a URL
   in it, highlight the address and maybe even get it to the point where
   it becomes a clickable link that spawns gnome-moz-remote or
   something.  In the gnome-terminal it's called "dingus clicking" and
   it's a very handy feature.  It's also part of gaim and is nice
   there too.  And if a message is all HTML, maybe strip the HTML tags or
   something so it doesn't look like complete crap.

** Full keyboard support.

   People have been requesting key bindings (those true linux hackers I
   guess hate mice), and we should give it to them.  The support is good
   enough as to make it easy, we just need a good listing of what
   keybindings people want to have and basic descriptions that would help
   us implement them and we're there. 

** Binary packages for any system.

   Not everybody can compile.  Not everybody likes to compile.  So, we
   should definitely have binary packages of version 1.0 available to
   cover just about all platforms.  This should include: redhat (.rpm),
   slackware (.tgz), debian (.deb), stampede (they use .slp right?), as
   well as binaries for other Unices such as FreeBSD, Solaris, and
   whatever else.  We can make some of these ourselves, but it'd be a
   good idea to make connections with others who mantain binary
   distributions who can get us going in these other formats.

** Documentation.

   Documentation is key.  We definitely need a users manual.  An on-line
   help file would be nice too, but I'm not sure what the standard help
   file is supposed to be like in GNOME (windows had the common help file
   format and stuff).  The FAQ needs to grow and spread apart into
   separate sections, and should also be distributed with the tarball.
   Basically, we need to make a 'docs' subdir and use it.

** Bug-free.

   Is it even possible? Maybe not.  But by this I mean that hopefully by
   version 1.0 we will have done a lot of version 0.9.x's and 1.0-pre
   releases such that we won't follow up the 1.0 release with 1.0.1 two
   days later and then 1.0.2 a day after that with 1.0.3 the week after.
   It'd be nice to have version 1.0 be ultra-stable.

//////////////////////////////////////////////////////////////////////

gnksa checklist
<http://www.xs4all.nl/~js/gnksa/gnksa.txt>

Checklist
=========                                                       (M)UST /
                                                                (S)HOULD
1) Displays all essential header information
   Software clearly displays:
   [Y] a) Article's author (From)                                      M
   [Y] b) Article's Subject                                            M
   [Y] c) List of groups posted to (Newsgroups)                        M
   [Y] d) Where (and how) to direct followups (Followup-To)            M
   [Y] e) Where to reply to if not the From-address (Reply-To)         M

2) Provides clear, separate commands for new  posting, followup, and
   e-mail reply
   [Y] a) for posting a new article                                    M
   [Y] b) for posting a followup article                               M
   [Y] c) for replying by e-mail                                       M
   [Y] d) Uses standard terminology                                    S
   [Y] e) Avoids ambiguous terminology                                 S

3) Provides cross-posting functionality
   [Y] a) Allows specifying multiple groups                            M
   [Y] b) Warns about, or prevents, posting to large numbers of groups S
   [Y] c) Strongly encourages setting Followup-To: on large crossposts S
          (`Y' if large crosspostings are disallowed)

4) Allows users to change essential headers
   [Y] a) Allows editing Subject at all times during composition       M
   [Y] b) Allows specifying new Subject of at least 70 characters      M
   [Y] c) Allows setting "Followup-To: poster"                         M

5) Ensures followups and e-mail replies contain a correct Subject
   [Y] a) Prepends "Re: " if (and only if) not already present         M
   [Y] b) Preserves entire original Subject (modulo minor repairs)     M

6) Directs followups to the correct newsgroups
   [Y] a) Initiates e-mail reply rather than a followup posting on
          "Followup-To: poster", clearly informing the user            M
   [Y] b) Posts to groups in Followup-To if present                    M
   [Y] c) Posts to groups in Newsgroups otherwise                      M

7) Make sure followups contain valid References
   [Y] a) Creates References header with Message-ID of original article
          as the last element                                          M
   [Y] b) Includes last three References from original                 M
   [Y] c) Ensures References will fit in 998 characters                M
   [Y] d) Keep as many References from original as fit                 S
   [N] e) Does not propagate broken Message-IDs in original References S

8) Direct e-mail replies to the correct address
   [Y] a) Uses Reply-To if present                                     M
   [Y] b) Uses From address otherwise                                  M

9) Allow the user to change her mind about whether to post or mail (or
   do both) and behave if doing both
   [Y] a) Allows users to change their mind and mail rather than
          post after having initiated a followup message               S
   [Y] b) Allows users to change their mind and post rather than
          mail after having initiated a reply message                  S
   [Y] c) Does not offer both posting and mailing as default behaviour M
   [Y] d) Inserts a notification that the message was posted as well
          as mailed in the e-mail copy when both posting and mailing
          a followup article                                           S

10) Provide adequate quotation and attribution facilities
    [Y] a) Allows including quoted original                            M
    [Y] b) Clearly distinguishes quoted material                       M
    [Y] c) Prefixes quoted material with `>'/`> '                      S
    [Y] d) Omits correctly delimited signatures from quoted material   S
    [Y] e) Provides a means of indicating which part(s) to followup to S
    [Y] f) Attribution line containing original author precedes quotes M

11) Provide a user-specified "Subject: " header
    [Y] a) Requires non-empty, user-specified Subject for new articles M
    [Y] b) Refuses posting articles without, or with an empty, Subject M
    [Y] c) Does not provide default Subject if user did not set one    M
    [Y] d) Allows changing the Subject at any time while editing       M

12) Provide a valid "From: " header
    [Y] a) Sets "From: " header to syntactically valid e-mail address  M
    [Y] b) Refuses posting articles without a syntactically valid
           "From: " header                                             M
    [N] c) Uses correct e-mail addresses (valid and belonging to the
           user) only, as far as it can possibly know                  S

13) Allow users to both cancel and supersede their own articles (and
    _no_ others!)
    [N] a) Allows cancelling articles                                  S
    [N] b) Allows superseding articles                                 S
    [Y] c) As far as possible, does not allow cancelling or superseding
           other peoples' articles                                     M
    [N] d) Uses standard terminology                                   S

14) Try to respect the 80-character line-length convention
    [Y] a) Articles are posted as edited, with linebreaking intact     S
    [Y] b) Warns about lines over 80 characters                        S
    [Y] c) Does not refuse to post articles containing long lines      S
    [N] d) Allows rewrapping quoted text                               S
    [Y] e) Enforces formatting requirements on article after external
           editing (`Y' if there is no support for external editors)   S

15) Separate signatures correctly, and don't use excessive ones
    [Y] a) Uses (and enforces) standard signature delimiter            S
    [Y] b) Warns against or refuses to use excessive signatures        S

16) Try to prevent obvious user errors
    [Y] a) Warns when attempting to post empty articles                M
    [Y] b) Refuses posting empty articles                              S
    [Y] c) Warns when post articles containing quoted material only    M
    [Y] d) Refuses posting quoted-text-only articles                   S
    [Y] e) Warns against posting multiple copies (`Y' if impossible)   M
    [Y] f) Prevents multiple posting entirely                          S

17) Post human-readable articles unless ordered otherwise
    [Y] Does not (and can not) encode or encrypt articles unless
        on explicit user demand                                        M

18) Provide self-protection
    [Y] Allows filtering out annoying articles (killing)               S

19) Be kind to servers, leave room for others
    [Y] a) Does not unnecessarily open multiple connections            M
    [Y] b) Does not generate excessive server load otherwise           M
