So far it saves when modified and does not otherwise, quite reliably. In this case, it's better to err on the side of caution, so if it
over-saves,
I won't mind; only if it fails to save a changed document we have a
problem.
If the `Save' menu item isn't greyed out, then it should attempt to save, or at least read in the file and check that no save is necessary. (This may also alert us to problems with the modifiedness tag.)
We currently have no graying out in menus. Many commands, not only save, will need to grey out when they have nothing to do. This is another major UI task.
It can be useful for the user to know if the document has been modified. (E.g. does it need re-uploading or reprinting or whatever.) Greying out the `Save' menu item is one way of providing this information; though if we really value this information then a "louder" indication may be warranted: e.g. change of title bar (append ` (modified)'), or status bar change.
Normally programs display a "*" in the window bar. I think we must have this too.
_________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%...
On Tue, 2003-12-16 at 22:35, bulia byak wrote:
We currently have no graying out in menus. Many commands, not only save, will need to grey out when they have nothing to do. This is another major UI task.
sp_action_set_sensitive() can be used to grey out or enable all menu items and buttons attached to that action.
For the save button, that might mean the SPDesktop code sets up a callback when sodipodi:modified changes, which would get the SPAction for SP_VERB_FILE_SAVE and call sp_action_set_sensitive() as appropriate.
Of course, this also requires per-SPView actions to be of any use... I guess I should go implement those now...
-mental
participants (2)
-
bulia byak -
MenTaLguY