From Inkscape Wiki
Revision as of 17:50, 15 December 2003 by Buliabyak (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

New statusbar API

There are new functions for statusbar display. Please use them where appropriate to make statusbar helpful and informative:

void sp_view_set_statusf (SPView *view, const gchar *format, ...);

Sets statusbar message permanently. The format string and the rest of arguments are as in printf(). Not to be used normally, because the message never disappears unless replaced by another message. In the majority of situations, one of the _flash or _error functions should be used instead.

void sp_view_clear_status (SPView *view);

Clears statusbar message permanently. Not to be used normally. In the majority of situations, one of the _flash or _error functions should be used instead.

void sp_view_set_statusf_flash (SPView *view, const gchar *format, ...);

Displays message temporarily for 1 second; when the message disappears, the one that was in the statusbar before it is restored. Use this function for short helpful hints or explanations of non-trivial actions. Examples: "No-break space" when you press ctrl-space in text object; "Closing path" when hitting the anchor in freehand; "Selection cancelled" when pressing Esc cancelled rubberband selection.

void sp_view_set_statusf_error (SPView *view, const gchar *format, ...);

Displays message temporarily for 5 seconds; when the message disappears, the one that was in the statusbar before it is restored. Use this function for most non-fatal error messages (unless they are so important as to warrant a modal messagebox). Examples: "To join, you must have two endnodes selected" when you try to join nodes that are not exactly two endpoints; "To subtract, you must have two objects selected" for the boolean difference operation.

The only potential difficulty with these functions is figuring out the SPView. How you do this depends on what you have at hand when you call one of these functions. Examples:

SPEventContext *ec;
sp_view_set_statusf_flash (SP_VIEW(ec->desktop), format, ...);
SPSelection *sel;
sp_view_set_statusf_flash (SP_VIEW(sel->desktop), format, ...);
SPNodePath *nodepath;
sp_view_set_statusf_flash (SP_VIEW(nodepath->desktop), format, ...);

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