14,154d13
< <a name="Items that Need to Be Checked for Fixing as Necessary (11jul04)">
< <h4>
< 2.17.1.  Items that Need to Be Checked for Fixing as Necessary (11jul04)
< </h4>
< </a>
< <ul>
< <li>
< Figure out what to do with duration arrows when they span a day break or would
< cross over another item.  I'd say an ellipses would be just right, either horz
< or vert.  Related to this, be sure to figure out what the display should look
< like in extreme cases for all display options, such as a screen too small to
< show fine day-view increments, such as every 10 minutes.
< <li>
< creating distributions in the admin section, to make things crystal clear about
< what's in <tt>Settings</tt> versus what's part of the application.  Also clear
< up bit about exactly now Distribution name is used, and the "any other
< necessary installation support files"
< <li>
< Base Defaults subsection in options, in particular figuring out whether a
< custom distribution overrides base defaults in the app itself, or puts them in
< the distributed <tt>Settings</tt> file (it needs to be the latter if (c) is
< going to be the choice in the next item (which I really think it should be))
< <li>
< Somewhere, if anywhere, in the options section, figure out if we want a
< `<tt>restore base defaults option settings</tt>' command.  It could be (a) a
< button in the options dialog (yuck); (b) the bottommost item in the Options
< menu (sort of yuck); (c) nowhere (I think I like this the best).  The good
< argument for (c) is that the user can simply remove or rename the
< <tt>Settings</tt> file to get back the base defaults (see second choice in
< immediately preceding bullet).  NO -- simply removing the <tt>Settings</tt>
< file to restore base default options is messed up, because it also gets rid of
< other non-option settings that the user may well want to keep.  So, we're back
< to some kind of `<tt>restore base defaults</tt>' command, resumably in the
< bottom part of the menu.
< <li>
< UPDATE: we are <em>not</em> going to lose the <tt>start-up calendar</tt> field
< in the distribtuion, since we've fixed things in the revised options section;
< we do still need to deal with the issue of the user ID of the distribution-
< supplied file becoming that of the user, but we've already started to deal with
< this in the File section.  OLD THINGS, NOW NOT HAPPENING: I think we should
< lose the `<tt>start-up calendar</tt>' in the distribution dialog, since the
< (newly explained) way it's effected is convoluted, and if it's there the
< installation should include a calendar of that name (which is a pain and pretty
< useless); if we care, we can have some sample calendars around to include at
< some web site or make part of the larger "distribution" of the thing.  But we
< can forget about this for now.
< <li>
< Check out any other things in the new file section, as it relates to the dmin
< and options sections in particular.
< <li>
< Fix all refs to the <tt>Local Files</tt> section to whatever new name it ends
< up with.
< <li>
< Deal with the one new item at bottom of options menu in ui-overview and options
< sections.
< </ul><font color=black>
< 
< <a name="Delete Shortcut">
< <h4>
< 2.17.2.  Delete Shortcut
< </h4>
< </a>
< <p>
< Allow use of delete key on selected item in a larger-grain view.  There should
< be a related toggle option `<tt>warn on delete via short cut</tt>', perhaps
< just an option `<tt>warn on delete</tt>'.
< 
< <a name="Cut Bit from Options Section">
< <h4>
< 2.17.3.  Cut Bit from Options Section
< </h4>
< </a>
< </p><p>
< Remember the bit about the initialization file and how it deals with the
< default view level always happening, including how a "no window" option value
< affects things initialization-filewise.
< 
< <a name="Global Date Update">
< <h4>
< 2.17.4.  Global Date Update
< </h4>
< </a>
< </p><p>
< Turns out, 2009 has the same day config as 1998, so we should globally replace
< all occurances of "1998" and "98" (as a year) with "[20]09".  Fun.
< 
< <a name="HTML Links">
< <h4>
< 2.17.5.  HTML Links
< </h4>
< </a>
< </p><p>
< Allow them in the <tt>Title</tt> and <tt>Details</tt>.  In particular, just
< allow any HTML tags to appear in <tt>Title</tt> and <tt>Details</tt>, a la
< Javadoc.  Thinking this through a bit more, there may need to be some
< limitation on what tags can appear in the Title field, since it's just a one-
< liner.  Also, we need to think through just how HTML will be displayed versus
< edited.
< </p><p>
< This is starting to feel like a pretty big can-o-worms, actually, particularly
< if we want to provide text formating in the fields.  We may want to take a cue
< from the way Apple Mail works, where there is an explicit distinction between
< plain text versus HTML content.  We might have a few commands to set fonts and
< text properties in some menu somewhere, or we may just have a 'view source'
< command to allow the HTML content of messages to be edited.  Or maybe we could
< do this: have a radio button selector for how to view the content of the fields
< -- `<tt>Plain Text</tt>' versus `<tt>HTML</tt>'.  When `<tt>Plain Text</tt>' is
< selected, the fields show as that, including the raw HTML commands if they're
< present.  This allows such commands to be edited directly in the field.  When
< `<tt>HTML</tt>' is selected, then the field content is rendered as HTML, with
< the special feature that any fully plain text content is rendered properly as
< HTML filled text paragraphs (not just as &lt;pre&gt; ... &lt;/pre&gt;).  When
< `<tt>HTML</tt>' is selected and there are HTML tags present, then they're
< properly rendered.  Also, it seems that it may be appropriate to disallow
< editing when `<tt>HTML</tt>' is selected, to avoid having to lapse into WYSIWIG
< editing.  This may feel a little funky, unless, say, a quick little message
< pops up when the user tries to edit when in HTML display mode.  Or perhaps we
< could have it that (controllable as an option) as soon as the user tries to
< edit in HTML display mode, the system automatically switches to plain text
< mode, and attempts to place the cursor as close to the click location as it can
< (which could get tricky in terms of have figuring out the proper char position
< with all of the tags "not counting", as it were.  This is starting to sound a
< lot like future work.
< </p><p>
< Implementationwise, I'm hoping that we can just use a <tt>JTextEditorPane</tt>
< to make this happen easily, including some kind of forced one-line version for
< the Title field.
< 
< <a name="``Obvious'' Minimum GUI Requiremets">
< <h4>
< 2.17.6.  ``Obvious'' Minimum GUI Requiremets
< </h4>
< </a>
< </p><p>
< Drag feedback; no flashing visual artifacts; all displays with text-entry
< fields and areas must be resizable, all windows must have title bars as shown
< in the scenarios, all icons (minized forms) must have platform-appropriate
< abbreviated text/graphics.  These requirements fit very well under the heading
< ``things that experienced programmers/analysts know that can go wrong with
< typical implementations''.
< 
157c16
< 2.17.7.  Product Evolution
---
> 2.17.1.  Product Evolution
160c19
< </p><p>
---
> <p>
166c25
< 2.17.8.  Reminder
---
> 2.17.2.  Reminder
175c34
< 2.17.9.  Bug
---
> 2.17.3.  Bug
184c43
< 2.17.10.  The Term ``Client''
---
> 2.17.4.  The Term ``Client''
192c51
< 2.17.11.  Window ``Banner'' versus ``Title''
---
> 2.17.5.  Window ``Banner'' versus ``Title''
211c70
< 2.17.12.  Filtering Todo Items
---
> 2.17.6.  Filtering Todo Items
225c84
< 2.17.13.  Options Section Wording Fodder that Will Probably Be Nuked
---
> 2.17.7.  Options Section Wording Fodder that Will Probably Be Nuked
235c94
< 2.17.14.  Possible Fix Needed
---
> 2.17.8.  Possible Fix Needed
241c100
< a paragraph of Section 2.4.1.1 just above Figure 89
---
> a paragraph of Section 2.4.1.1 just above Figure 90
252c111
< 2.17.15.  Fix Links in Admin Section
---
> 2.17.9.  Fix Links in Admin Section
264c123
< 2.17.16.  Filtering Update Needed
---
> 2.17.10.  Filtering Update Needed
273c132
< 2.17.17.  Tree Viewer for Groups and Other Admin-Related Discussion
---
> 2.17.11.  Tree Viewer for Groups and Other Admin-Related Discussion
291c150
< 2.17.18.  External Operating Environment Issues
---
> 2.17.12.  External Operating Environment Issues
322c181
< 2.17.19.  Custom Filter Menu Options
---
> 2.17.13.  Custom Filter Menu Options
332c191
< 2.17.20.  Misc
---
> 2.17.14.  Misc
349c208
< Figure 109.
---
> Figure 110.
359c218
< 2.17.21.  Make Sure Button and Menu Item States are Accurate
---
> 2.17.15.  Make Sure Button and Menu Item States are Accurate
367c226
< Figure 91
---
> Figure 92
384c243
< 2.17.22.  Quick Note
---
> 2.17.16.  Quick Note
394c253
< 2.17.23.  Hmm, Centralized Server Architecture Rears Its Ugly Head
---
> 2.17.17.  Hmm, Centralized Server Architecture Rears Its Ugly Head
449c308
< 2.17.24.  Nuked These Things and Think They Can Stay Nuked
---
> 2.17.18.  Nuked These Things and Think They Can Stay Nuked
466c325
< 2.17.25.  Scripting Language Derived from UI Command
---
> 2.17.19.  Scripting Language Derived from UI Command
475c334
< 2.17.26.  A Couple More Todo Items
---
> 2.17.20.  A Couple More Todo Items
495c354
< 2.17.27.  Prev/Next Arrow Issue
---
> 2.17.21.  Prev/Next Arrow Issue
513c372
< 2.17.28.  Make Sure that Disabled (Greyed) State of All Buttons is Correct
---
> 2.17.22.  Make Sure that Disabled (Greyed) State of All Buttons is Correct
528c387
< 2.17.29.  Consider Where To Put Dialog State Details
---
> 2.17.23.  Consider Where To Put Dialog State Details
610c469
< 2.17.30.  Maybe for custom list section
---
> 2.17.24.  Maybe for custom list section
619c478
< 2.17.31.  Consider adding Emacs to list of related systems in section 1.5
---
> 2.17.25.  Consider adding Emacs to list of related systems in section 1.5
627c486
< 2.17.32.  Complete Clear Statement for Item Uniqueness Criteria
---
> 2.17.26.  Complete Clear Statement for Item Uniqueness Criteria
657c516
< 2.17.33.  Check Consistency between Task Scheduling and Task List Sections
---
> 2.17.27.  Check Consistency between Task Scheduling and Task List Sections
674c533
< 2.17.34.  Default Task Priority
---
> 2.17.28.  Default Task Priority
688c547
< 2.17.35.  Color
---
> 2.17.29.  Color
694c553
< Figure 10
---
> Figure 11
704c563
< 2.17.36.  Beware (potentially) of automatic rescheduling
---
> 2.17.30.  Beware (potentially) of automatic rescheduling
728c587
< 2.17.37.  General fixes and updates to do
---
> 2.17.31.  General fixes and updates to do
757c616
< Figure 6
---
> Figure 7
762c621
< Figure 5.
---
> Figure 6.
821c680
< 2.17.38.  General Constraints
---
> 2.17.32.  General Constraints
841c700
< 2.17.39.  Commands with No Effect
---
> 2.17.33.  Commands with No Effect
859c718
< 2.17.40.  Trimming
---
> 2.17.34.  Trimming
872c731
< 2.17.41.  Uniform Effect of the 'Cancel' Command
---
> 2.17.35.  Uniform Effect of the 'Cancel' Command
881c740
< 2.17.42.  Explanatory Error and Confirmation Dialogs
---
> 2.17.36.  Explanatory Error and Confirmation Dialogs
892c751
< 2.17.43.  Help
---
> 2.17.37.  Help
898c757
< 2.17.43.1.  Possible Options
---
> 2.17.37.1.  Possible Options
927c786
< 2.17.43.2.  Paragraph (from Rolodex) about Quick Help Activation Area
---
> 2.17.37.2.  Paragraph (from Rolodex) about Quick Help Activation Area
936d794
<