Difference between revisions of "StatusBar"
Jump to navigation
Jump to search
(remove "online casino spam") |
|||
| Line 1: | Line 1: | ||
------ | |||
We need to expand the use of the status bar to make it more useful and informative. Ideas: | We need to expand the use of the status bar to make it more useful and informative. Ideas: | ||
* (DONE) In node edit, it should display "X of Y nodes selected"; if only one node is selected, it adds its type (cusp, smooth, etc.) | |||
* In selector and node edit, if there are more than one object/node selected but all selected objects/nodes are of the same type, it must display that type; e.g. "5 rectangles" instead of "5 objects" and "5 of 10 nodes selected; all smooth" instead of just "5 of 10 nodes selected". | |||
* (DONE) Warnings and errors that could make sense for the end user (but are not so important as to warrant a modal messagebox) must be put into the status bar. An example is "Non-printable character" warning in text tool. Another example is the failure to perform an action such as the one described in [http://sourceforge.net/tracker/index.php?func=detail&aid=843373&group_id=93438&atid=604306 bug 843373]. | |||
* (DONE) Any complex or non-trivial actions must use the status bar to provide details or indicate success. An example is the Unicode mode in text editor. | |||
* If the document has been modified from its saved state, this should be shown | |||
::Isn't it standard to indicate that by adding * to the window title? --bb | |||
* (DONE for tools) Any currently active 'modes' should be indicated | |||
* (DONE, timeouts are implemented) We should consider exposing a slightly richer interface for setting the status bar contents (possibly exposing the GTK status bar push/pop metaphor?) | |||
** What might be the advantages of push/pop compared to the current "always overwrite"? --bb | |||
** Instead, I think about a function for temporary display: you say e.g. <tt>statusbar_display_timed("Message", 4);</tt> and the message is shown but disappears after 4 seconds (if it's still there, i.e. not replaced by any other message). This is useful for information which may be helpful but will annoy if displayed forever. --bb | |||
* Please add more ideas for where status bar display would be appropriate. | |||
----- | |||
Only one comment, we need to make sure that errors that happen in documents that are not in focus, stay with that status bar. So something like a filter warning would be posted to the window that it's running on - not the one your currently working on. --Ted | Only one comment, we need to make sure that errors that happen in documents that are not in focus, stay with that status bar. So something like a filter warning would be posted to the window that it's running on - not the one your currently working on. --Ted | ||
:This is taken care of by the signals; just provide the correct SPView in the function calls and it will update its statusbar. --bb | |||
Revision as of 13:03, 7 July 2004
We need to expand the use of the status bar to make it more useful and informative. Ideas:
- (DONE) In node edit, it should display "X of Y nodes selected"; if only one node is selected, it adds its type (cusp, smooth, etc.)
- In selector and node edit, if there are more than one object/node selected but all selected objects/nodes are of the same type, it must display that type; e.g. "5 rectangles" instead of "5 objects" and "5 of 10 nodes selected; all smooth" instead of just "5 of 10 nodes selected".
- (DONE) Warnings and errors that could make sense for the end user (but are not so important as to warrant a modal messagebox) must be put into the status bar. An example is "Non-printable character" warning in text tool. Another example is the failure to perform an action such as the one described in bug 843373.
- (DONE) Any complex or non-trivial actions must use the status bar to provide details or indicate success. An example is the Unicode mode in text editor.
- If the document has been modified from its saved state, this should be shown
- Isn't it standard to indicate that by adding * to the window title? --bb
- (DONE for tools) Any currently active 'modes' should be indicated
- (DONE, timeouts are implemented) We should consider exposing a slightly richer interface for setting the status bar contents (possibly exposing the GTK status bar push/pop metaphor?)
- What might be the advantages of push/pop compared to the current "always overwrite"? --bb
- Instead, I think about a function for temporary display: you say e.g. statusbar_display_timed("Message", 4); and the message is shown but disappears after 4 seconds (if it's still there, i.e. not replaced by any other message). This is useful for information which may be helpful but will annoy if displayed forever. --bb
- Please add more ideas for where status bar display would be appropriate.
Only one comment, we need to make sure that errors that happen in documents that are not in focus, stay with that status bar. So something like a filter warning would be posted to the window that it's running on - not the one your currently working on. --Ted
- This is taken care of by the signals; just provide the correct SPView in the function calls and it will update its statusbar. --bb