Bug 87540

On Thursday 19 August 2004 21:02, markus@relix.de wrote:
> This is a usability issue: Most other KDE applications that have a save-button
> (Icon), will display as inactive (or not available, i.e., grey) directly after 
> saving as long as nothing has been changed on the data (here: on the document).  

Which applications?

AFAIK the KDE-wide decision was that saving should always be allowed,
because e.g. the user might feel safer being able to save at any time,
or because the file could be removed from the disk and then you need
to press "save" again to recreate it. I can't find confirmation of that
in the KDE HIG though.

Hi David,

just take kaddressbook (3.2.1). When I click on the "save" icon (the little 
disk), the application saves all the data and the icon will remain grey until 
I modify something. I find this intuitive. 

I also checked your argument: kwrite does it like you said. There this button 
is always active, no matter if the document needs saving or not. 

Anyway, there should be a consolidated handling of these things, and I would 
prefer to have it as in windows, since this makes user migration easier. 

Nevertheless, you also have a point.

Though, the icon is for saving quickly and for providing the information if 
the document _needs_ saving. 

If the document does not need saving and the user wants to save out of line to 
be sure, he may select the menu entry... 

Regards,
Markus
... and thanks for replying so fast!

Am Freitag, 20. August 2004 15:26 schrieb David Faure:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
> You are a voter for the bug, or are watching someone who is.
>
> http://bugs.kde.org/show_bug.cgi?id=87540
>
>
>
>
> ------- Additional Comments From faure kde org  2004-08-20 15:26 -------
>
> On Thursday 19 August 2004 21:02, markus relix de wrote:
> > This is a usability issue: Most other KDE applications that have a
> > save-button (Icon), will display as inactive (or not available, i.e.,
> > grey) directly after saving as long as nothing has been changed on the
> > data (here: on the document).
>
> Which applications?
>
> AFAIK the KDE-wide decision was that saving should always be allowed,
> because e.g. the user might feel safer being able to save at any time,
> or because the file could be removed from the disk and then you need
> to press "save" again to recreate it. I can't find confirmation of that
> in the KDE HIG though.

David,
This is the feature of kwrite that I like the most.
The save-button becoming inactive when is unnecessary to save the document gives to editor a very more professional look. It is one of the features in linux that windows don't have and makes a great difference.
In the beginning, the user problably doesn't trust in the icon (I didn't too), only because windows haven't this, but, with experience, the user learn to trust in the icon state. The same for the indicator in the title bar that the documents was modified.

> This is the feature of kwrite that I like the most.
> The save-button becoming inactive when is unnecessary to save the document
> gives to editor a very more professional look. It is one of the features in
> linux that windows don't have and makes a great difference. In the
> beginning, the user problably doesn't trust in the icon (I didn't too),
> only because windows haven't this, but, with experience, the user learn to
> trust in the icon state. The same for the indicator in the title bar that
> the documents was modified.

Raul,

which version of kwrite do you use? I have KWrite 4.3 (3.3.0) and it doesn't 
behave as you describe. 

We both agree that it is highly useful if the icon informs the user if/that 
the document _needs_ saving. 

Having the button display this information is a bonus of usability - instead 
of just having a button to click on. 

Markus

Keeping the menu entry enabled regardless of whether the icon is enabled is important IMO.

On Friday 20 August 2004 23:30, Raul Fernandes wrote:
(...)
> This is the feature of kwrite that I like the most.

It was removed in Kate, so that you can always save. (Nothing is worse than 
when the application things you do not need to save, when you have to save.)

(...)

> Keeping the menu entry enabled regardless of whether the icon is enabled is important IMO.
That's a confusing statement. Do you really mean that the menu item and the toolbar button
should act differently? This makes no sense to me (they represent the same action).
Technically it's the same KAction too, which makes them consistent :)

Markus said:
> We both agree that it is highly useful if the icon informs the user if/that 
> the document _needs_ saving. 
But the application can't know if e.g. I removed the file from where I saved
it last; don't only think of the local file system btw, all kde apps support
working on files on an FTP site, for instance (so simply checking for existence
would be slow and cumbersome).

Knowing whether you need to save or not is already indicated, by the [Modified] in the
caption, the floppy disk in the taskbar, etc. But _preventing_ the user from saving
is certainly not a good idea - my wife certainly wants to save just before closing
the window or the computer, "just to be sure", and disabling the save action would
only frustrate her :)

The kaddressbook behavior is a bug IMHO. I even think saving changes should be
automatic in the addressbook, but that's another topic.

> Keeping the menu entry enabled regardless of whether the icon is enabled is
> important IMO.
Yes, This is what I forgot to outline. The icon should turn grey, the menu 
item should still be enabled. 

I had thought of this feature but not of the possibility that the file may be in the meanwhile deleted from disk. If the menu item is disabled and the toolbar item is disabled then it would be very inconvenient. I agree with comment #1.

Menu entry and toolbar buttons must stay consistent with each other, this is a basic GUI rule in kde.

WONTFIX is right, but not because of consistency. If consistency is needed, one could disable both the menu item and the toolbar. This is a WONTFIX due to the deletion argument put forth in comment #1.