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

* Short-term TODO: Pan 0.7.6 (Tuesday, February 22, 2000)

[Charles]
[ ] http://www.debian.org/Bugs/db/50/50897.html
[ ] unread count not updated when you download/decode a mesasge
[ ] stop all (right-click?)
[ ] remove alt-accelerators; they screw up I18N
[ ] put server selection into the menus
[ ] prefs option to check server for new messages when you load a group
[ ] show all headers
[ ] gnksa 7e
[ ] gnksa 12c -- we may not want to do this
[ ] gnksa 13a -- this may be a 0.7.5
[ ] gnksa 13b -- this may be a 0.7.5
[ ] gnksa 13c -- this may be a 0.7.5
[ ] gnksa 13d -- this may be a 0.7.5
[ ] gnksa 14d -- this may be a 0.7.5
[ ] Better tracking of article threads (a "Watch" function from a popup menu)

[Matt]
[ ] Stop pimping around at your new job and get back to hacking Pan ;)

[Jason]
[ ] Add a "Get all new headers from all subscribed groups" menu & shortcut
[ ] 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)

[Unclaimed]
[ ] acache check the body line count; we can catch incomplete files this way
[ ] "Wrap Text" option
[ ] xnews-like text toolbar
[ ] watch thread -- a menu option instead of having to use the killfile dialog
[ ] kill thread -- a menu option instead of having to use the killfile dialog
[ ] online/offline mode
[ ] find some I18N translators to update/add po files
[ ] queue manager?
[ ] 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.

[BUGS]
[ ] >1 user reporting bugs with I18N -- some characters trash the line.
[ ] >1 user reporting bugs with menu insertions. (I18N?)
[ ] >1 user reporting bugs with opening bdb database file.
[ ] I18N encoding of header information -- rfc 1342
    http://andrew2.andrew.cmu.edu/rfc/rfc1342.html

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

0.7.X Checklist

[ ] hooks for going on/offline
[ ] more search options to "find" dialog?
[ ] right clicking on article should have more options
[ ] log viewer improvements: coloring based on priority, error, etc
[ ] queue manager
[ ] reorganize the prefs dialog to use a tree on the lhs; we're streching
    the tab metaphor about as far as it can go
[ ] toolbar or buttonbar ?
    ( ) online/offline
    ( ) stop all
    ( ) download and decode selected
    ( ) get new headers from selected groups
[ ] per-group configuration options: logging
[~] tooltips
[~] nice icons and graphics.
[ ] ability to attach files to posts.
[ ] when deleting a set of articles, the article list moves to somewhere near
[ ] add "Delete Attachment" popup, that when clicked deletes the decoded
    article from the download dir (if it's still there), and cached
    headers/bodies.

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

Wishlist

[ ] group-centric design
[ ] .newsrc support
[ ] URL grabbing (from message bodies), see gaim's conversation.c
    (linkify_text()) for examples/more detail.
[ ] Space reading: hitting space pages down in the text window; at end, goes to next message.

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

* Long-term TODO: Pan 1.0

[Charles' pie-in-the-sky suggestions]

** User folders for saving articles they want to keep & read in Pan

[Jason's pie-in-the-sky suggestions]

** 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
