RE: ANNOUNCE: Style Guide available for review.

[Paul Hepworth <phepworth s-vision com>]

> >(Can we force window managers to provide a [?] button for use with
> short
> >"what is this?" popup descriptions?  If so, all controls shall
> respond
> >to the "what is this" message.)
> 
> One more button?
> Why not just the Ballon Help (correct name?)? You moves the mouse over
> a
> button and after x secs (user config definable) a short message
> appears.
> Novices will explore using less time, and experts can disable it.
> Perfect for all, is not it?
> 
You mean like tooltips?  Maybe, hold it here for X seconds, the tooltip
appears.  Click the tiny little "more info button" inside the tooltip
and the few-line "what it is and how to use it" baloon appears in the
tooltip's place.  I like it! 

> >"Applicatins should not allow users to change the default bindings
> for
> >common operations."
> >I *strongly* disagree!  See my posting on the key binding standard.
> 
> Hey, I disagree too. Keybindings should be user definable.
> Maybe a common database for keybindings, so all apps that
> cut/paste/copy
> have the same keys. Open, close, save, save as, close all, quit, help,
> undo,
> redo...
> 
Exactly!

> >"All operations that have a deterministic time to completion that
> lasts
> >more than three seconds should indicate progress using a progress
> bar."
> >Should this be configurable (system-wide, per user) instead of
> >arbitrarily three seconds?  (I don't like to see progress bars unless
> >the operation takes more like ten seconds.)
> 
> Not all people has the same computer. Some found normal to wait 10
> secs,
> others 5. User definable (like keybindings).
> 
Yup.

> >nitpicking:
> >be careful of use of "should" and "must" -- I saw some "shoulds" that
> >should be "musts."
> 
> KDE pages have some references to should must (and other words)
> meanings.
> I think they took them from a RFC.
> 
> >IHTH
> 
> What?
> 
I Hope This Helps

> >> No.  The number of menu items should not change.  If you want to
> show
> >> the last four documents, then there should always be four items for
> >> "last" documents, and if there is not sufficient history, then they
> >> should be greyed out.
> >agree;  alternatively, put a History item on the file menu that leads
> to
> >a cascade menu of the file history (of user-configurable length!)
> 
> Number of items should be user configurable, and a submenu will be
> cool. You
> can have 10 docs, but not need to see the list when you only are going
> to
> "save", "open" or anything in file menu except "load from history"
> "last
> loaded docs".
> 
Number of files to keep is yet another "global" (but per-user)
preference to put in th preferences database (along with keybindings,
fonts, colors, dialog sizes, etc.)
BTW, as was already suggested (regardless of how many to save the user
has configured), if there are not that many, empty entries should be
left there so that the "Exit" item always has the same position.


Paul