StatusBar - Revision history

VonHalenbach: Reverted edits by RapQj0 (Talk); changed back to last version by Colin Marquardt

2007-06-10T11:38:47Z

Reverted edits by RapQj0 (Talk); changed back to last version by Colin Marquardt

← Older revision		Revision as of 11:38, 10 June 2007
Line 7:		Line 7:
	* 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".		* 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		* (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

			:This is taken care of by the signals; just provide the correct SPView in the function calls and it will update its statusbar. --bb

			[[Category:Wiki Attic]]

RapQj0 at 06:02, 10 June 2007

2007-06-10T06:02:23Z

← Older revision		Revision as of 06:02, 10 June 2007
Line 7:		Line 7:
	* 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".		* 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) 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

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

	~~:This is taken care of by the signals; just provide the correct SPView in the function calls and it will update its statusbar. --bb~~

	~~[[Category:Wiki Attic]]~~

Colin Marquardt: Reverted edits by SvhYc0 (Talk); changed back to last version by GigaClon

2007-04-20T15:45:55Z

Reverted edits by SvhYc0 (Talk); changed back to last version by GigaClon

← Older revision		Revision as of 15:45, 20 April 2007
Line 7:		Line 7:
	* 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".		* 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		* (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

			:This is taken care of by the signals; just provide the correct SPView in the function calls and it will update its statusbar. --bb

			[[Category:Wiki Attic]]

SvhYc0 at 07:09, 11 April 2007

2007-04-11T07:09:22Z

← Older revision		Revision as of 07:09, 11 April 2007
Line 7:		Line 7:
	* 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".		* 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) 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

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

	~~:This is taken care of by the signals; just provide the correct SPView in the function calls and it will update its statusbar. --bb~~

	~~[[Category:Wiki Attic]]~~

GigaClon: Categorization

2006-06-20T17:55:38Z

Categorization

← Older revision		Revision as of 17:55, 20 June 2006
Line 27:		Line 27:

	:This is taken care of by the signals; just provide the correct SPView in the function calls and it will update its statusbar. --bb		:This is taken care of by the signals; just provide the correct SPView in the function calls and it will update its statusbar. --bb

			[[Category:Wiki Attic]]

Matiphas: *

2004-07-07T13:03:19Z

← Older revision		Revision as of 13:03, 7 July 2004
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.)		* (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".		* 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) 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.		* (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		* 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

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

	* ~~(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?)~~		* Please add more ideas for where status bar display would be appropriate.
	~~o What might be the advantages of push/pop compared to the current "always overwrite"? --bb~~
	~~o 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		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		:This is taken care of by the signals; just provide the correct SPView in the function calls and it will update its statusbar. --bb

Matiphas: remove "online casino spam"

2004-07-07T12:59:30Z

remove "online casino spam"

New page

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?)
o What might be the advantages of push/pop compared to the current "always overwrite"? --bb
o 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

Simarilius: fixing the mess made by casino

2004-07-06T17:05:07Z

fixing the mess made by casino

New page

------

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

:This is taken care of by the signals; just provide the correct SPView in the function calls and it will update its statusbar. --bb

Buliabyak: *

2004-01-01T21:02:39Z

← Older revision		Revision as of 21:02, 1 January 2004
Line 1:		Line 1:
	~~=== 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, ...);~~

	~~Please don't forget to enclose all text strings shown to the user into <tt>_("...")</tt> so they can be translated. For this to work, you need to <tt>#include "helper/sp-intl.h"</tt>.~~

Buliabyak: *

2004-01-01T20:45:28Z

← Older revision		Revision as of 20:45, 1 January 2004
Line 30:		Line 30:
	sp_view_set_statusf_flash (SP_VIEW(nodepath->desktop), format, ...);		sp_view_set_statusf_flash (SP_VIEW(nodepath->desktop), format, ...);

	Please don't forget to enclose all text strings shown to the user into _("...") so they can be translated.		Please don't forget to enclose all text strings shown to the user into <tt>_("...")</tt> so they can be translated. For this to work, you need to <tt>#include "helper/sp-intl.h"</tt>.