Version: 4.3 (using KDE 3.3.0, (3.1)) Compiler: gcc version 3.3.4 (Debian 1:3.3.4-7) OS: Linux (i686) release 2.4.24-pre1-xfs This issue is related to Bug 87540 http://bugs.kde.org/show_bug.cgi?id=87540 The save-icon should display the information if the document _needs_ saving. If the document has been saved and nothing has been changed, the icon should be grey and inactive. Instead the icon is always active and is thus not a means of feedback to the user. It is "just" a place to click on. There is only the indication in the title bar that says "modified". The latter disappears when the document is saved. Though, this information in the title bar is a little off-focus. If we want to provide maximum usability and ease of migration for former windows-users, we should implement a similar (or in this case identical) user dialog: The icon must display if the document needs saving.
it will be kept enabled the whole time, it is often very useful for a texteditor to just save the file again, e.g. if the file was altered by outside and the detection doesn't work (e.g. on unices without fam/dnotify/...), therefor it will be kept (even without that, it is nice to "touch" your file just by pressing save for example to trigger recompile, ....)
Christoph, > it will be kept enabled the whole time, it is often very useful for a > texteditor to just save the file again, e.g. if the file was altered by > outside and the detection doesn't work (e.g. on unices without > fam/dnotify/...), therefor it will be kept (even without that, it is nice > to "touch" your file just by pressing save for example to trigger > recompile, ....) Sure, giving the user the ability to save just as he wishes, is OK. But the user can do this by clicking on the menu entry, also. This issue is about enriching the application with a little feedback to the user. In other terms, the "[modified]" in the title bar is too little, because the title bar is simply out of focus. I really appreciate this sort of feedback under kaddressbook and many other applications. The user experience in Microsoft apps is also like that and there should be a smooth as possible migration by providing the same user experience, especially by such small things.
*** Bug 78363 has been marked as a duplicate of this bug. ***
*** Bug 105350 has been marked as a duplicate of this bug. ***
Just to repeat: this will not be changed. Kate allows you to save at any time, and the toolbar button represents the save action. Applications using the kate editor component (katepart) should show the state of a document by other means, for example in the title and/or status bar.
I use Quanta with many files opened, and for me it's really usable to see the state of the "save" icon in each file, because I can know quickly if the file has been modified without saving or not. I don't understand the possibility of Kate to save the file at any time, including without the file modified (what is the utility of this?). Anyway, my wish was for Kwrite but it has been moved here. I don't know the relation between Kate and Kwrite, I thouth they were different text editors.
Monday 09 May 2005 21:08 skrev ibc: > I use Quanta with many files opened, and for me it's really usable to see > the state of the "save" icon in each file, because I can know quickly if > the file has been modified without saving or not. It is up to quanta to visualize the 'modified state' of a document. Kate provides an icon in the status bar if the file is modified, as well as in the file list and the default KDE change of the title. So if you are unhappy with quanta, file a bug with them. > I don't understand the possibility of Kate to save the file at any time, > including without the file modified (what is the utility of this?). This is like touch(1). And it's a user request, and also makes sense in many cases. And once more: the toolbar icon is *NOT* there to show the 'modified state' of the document. Applications should make that visible using other means. > Anyway, my wish was for Kwrite but it has been moved here. I don't know the > relation between Kate and Kwrite, I thouth they were different text > editors. Kate, kwrite, quanta, kdevelop and several other applications that provides text editing uses katepart to do so. Bugs for katepart goes here.
As the submitter of this ticket I also found the current behaviour rather strange. Unfortunately I have the impression, that's something the developers have firmly decided on and there's no way to reach a deviating decision. Well, I can only emphasize once again that the icon bar is wasted space if it only serves as a field for clickbuttons. It could also carry some information and act bi-directional in this sense. I am firmy convinced that applications should have as few dialog elements as possible in order to reach maximum usability. A good application is not one with many buttons and many different informative gadgets, but instead it is sober, reductive in the number of dialog elements and simple to use. And this little feature is something we could really copy from M$... Hugh, I spoke my part. :-)) Regards Markus
Then you should go back and take another look at Microsoft's VisualStudio 6.0, 7.0, and their new Visual Studio Whidbey... The 'Save' icon acts just like Kate does... it remains on all the time. Having icons serve two purposes (for actions and for status) is sometimes very hairy... And furthermore, like Anders said, we use it to 'touch' a file to update it's modification time when we so choose.
El Lunes, 9 de Mayo de 2005 22:18, Anders Lund escribió: || Monday 09 May 2005 21:08 skrev ibc: || > I use Quanta with many files opened, and for me it's really usable to || > see the state of the "save" icon in each file, because I can know || > quickly if the file has been modified without saving or not. || || It is up to quanta to visualize the 'modified state' of a document. Kate || provides an icon in the status bar if the file is modified, as well as in || the file list and the default KDE change of the title. So if you are || unhappy with quanta, file a bug with them. Sotty, you didn't understand me. I really like the method of Quanta to show when a file has been modified (it shows enable the "save" icon in toolbar and shows [ ] containing the file name in the window and panel). || Kate, kwrite, quanta, kdevelop and several other applications that || provides text editing uses katepart to do so. Bugs for katepart goes here. OK, thanks for the explanation.
I'm happy with the explanation of the save button here, but I think that the same logic should not be extended to the "Save All" menu item/button. What happens is that all open files are saved. This causes read-only files to throw up dialogs, remote files to go through (unnecessary) expensive network operations, etc. I think the "Save All" button should only save the files that need saving. I believe this is the only interpretation of the user's intention.
Tuesday 10 May 2005 13:47 skrev Ryan Dalzell: > I'm happy with the explanation of the save button here, but I think that > the same logic should not be extended to the "Save All" menu item/button. > What happens is that all open files are saved. This causes read-only files > to throw up dialogs, remote files to go through (unnecessary) expensive > network operations, etc. > > I think the "Save All" button should only save the files that need saving. > I believe this is the only interpretation of the user's intention. Kates 'Save All' action only saves modified documents, and it should logically only be enabled if at least one document is modified.
Monday 09 May 2005 23:13 skrev markus@relix.de: > As the submitter of this ticket I also found the current behaviour rather > strange. Unfortunately I have the impression, that's something the > developers have firmly decided on and there's no way to reach a deviating > decision. It is NOT strange- The toolbar button (as any toolbar button) is enabled, when the action it represents is enabled. For kateparts save action, that is allways. > Well, I can only emphasize once again that the icon bar is wasted space if > it only serves as a field for clickbuttons. It could also carry some > information and act bi-directional in this sense. You are talking rubbish. The toolbar is a button bar. Each button represents an action, and is enabled when the action is. For example the 'copy' button is only enabled when there is a selection in the current view, and the paste only when there is text in the clipboard. Kateparts 'save' action is allways enabled, because you can save the document at any time.
My apologies, in Kate 3.4.0 the "Save All" does indeed only save files that need to be saved. I think I am remembering a deceased bug. The point about the toolbar button for "Save All" being enabled stands though.
Tuesday 10 May 2005 15:07 skrev Ryan Dalzell: > The point about the toolbar button for "Save All" being enabled stands > though. What point? The buttons state follows the actions state. I ask because I'm not sure that the actions state is updated. If not, we could fix it.
Yes, the "Save All" action state is not disabled when there are no modified files to save.