Version: 3.2 (using KDE 3.2 BRANCH >= 20040204, Gentoo) Compiler: gcc version 3.3.2 20040108 (Gentoo Linux 3.3.2-r6, propolice-3.3-7) OS: Linux (i686) release 2.6.2-mm1 Open Korganizer. Enter an event/appointment (double click on date, enter some info. CLOSE the windows. Bam!! You lose the info you just entered. Korganizer SHOULD ask "do you want to save" before closing.
Hm, from the bug report it's not entirely clear if the bug reporter meant that you loose the entered values if you just close the event edit window (using the button in the title bar, which is supposed to work like a Cance) or if the event is created, but lost when you exit korganizer. In the first case, I'd say the report is actually invalid (the X button in the title bar always behaves like Cancel, in all dialogs). In the latter case it's quite a serious bug as the standard calendar is supposed to be saved automatically. Reinhold
If the local file resource can't write the file there is no error message and KOrganizer just exist without getting the user a chance to save the data. I assume that's the problem here. What file name is shown in the dialog which appears when you click the edit button from the calendar list view at the bottom left of the KOrganizer main window? Does this file actually exist?
Subject: Re: propmpt for save on close Reinhold Kainhofer wrote: > In the first case, I'd say the report is actually invalid (the X button in > the title bar always behaves like Cancel, in all dialogs) Then change to make it means: CLOSE, i.e. ask "do you want to save?" Regards, Norberto
I was just going to report this as a bug. This is very serious. I just used KOrganizer for the first time today (after upgrading to KDE 3.2 and installing kdepim). I entered a bunch of events into my calendar and to-do list. They all showed up fine in the calendar. Then I closed KOrganizer by clicking the X in the corner, and let the KOrganizer Alarm Daemon run in the background. Then I opened KOrganizer again later and saw to my dismay that everything I had entered had been lost! It's as though I started KOrganizer for the first time, because it's completely empty. I assumed KOrganizer would be periodically saving my changes into some database whenever I added/modified an entry. I had no clue it was all just being stored in memory, and the user had to actually explicitly tell KOrganizer to write everything to disk. That's very unintuitive. KOrganizer shouldn't even prompt the user to save my changes - it should do it automatically before it shuts down. I don't know of another PIM that asks the user if they'd like to save their changes to a file before it closes; it's always done implicitly, the way it should be done.
There is something I noticed that might be related to this. When I first opened up korganizer after upgrading to KDE 3.2 (Gentoo linux, compiled from sources, kdepim-r2) I imported my old calendar, added a few events, saved and closed it. When I reopened it, all the new events were lost. It took me several tries before I could get it to save properly, and it appeared as though I needed to do a "merge calendar" and explicitly save it as std.ics in the ~/.kde/share/apps/korganizer/ directory. When I tried to saved it as an ics file with any other name into that directory all changes I made to it were lost.
Tucker wrote: > I imported my old calendar, added a few events, > saved and closed it. When I reopened it, all the new events were lost. No please, that's not the bug I'm describing. Please, file a new bug report for that. The bug (feature) I want to be fixes is: 1) Open KOrganizer. 2) Double click on march 1. 3) Enter "title" "location" etc... 4) Click on close button (windeco) KOrganizer doesn't ask you to save the event and you lost it. The close button is CLOSE, no CANCEL. And if it means CANCEL, then remove the d*mn CANCEL button on the bottom. Regards, Norberto
Comment #6: This is not a bug. The close button of the window decoration is equivalent to the cancel button. There is no confirmation dialog for that and there won't be one. That's how dialogs work in KDE.
Cornelius Schumacher wrote: > ------- Comment #6: This is not a bug. The close button of the window > decoration is equivalent to the cancel button. There is no confirmation > dialog for that and there won't be one. That's how dialogs work in KDE. Okay. Remove every CANCEL button then. Who should I talk to?
What about File->Quit? Or File->Save? They don't save changes to the calendar for me (Mandrake 10 RC1, KDE 3.2, kdepim-korganizer-3.2-19mdk)
Possibly related bug: bug 73017
Norberto explicitely stated that this bug report is about the x button in the window decoration. For all dialog boxes, the x button is equivalent to "cancel" or "close without action", so I regard this bug report INVALID. Imagine the "Open" or "save" dialog box would open or save the selected file when you click the "X"... To change the overall behaviour of all KDE dialogs, you better talk to the core developers at kde-core-devel@kde.org, although you will probably not be successful with that request (see also KDE's GUI style guide). One problem is that not all window decorations have a close button. The other problem mentioned by a reply to the bug is already known and a duplicate of another bug report. Cheers, Reinhold
Reinhold Kainhofer wrote: > For all dialog boxes, the x button is > equivalent to "cancel" or "close without action", so I regard this bug > report INVALID. Imagine the "Open" or "save" dialog box would open or save > the selected file when you click the "X"... I don't agree, but well, KDE is your creature. I'll patch korganizer for my own use so it behaves the way -I think- it should be. > To change the overall behaviour of all KDE dialogs, you better talk to the > core developers at kde-core-devel kde org... No, I don't want to change every dialog box behavior, only the one in korganizer. Thanks, Norberto
Let's make things clear first. I think this bug is about close button of MAIN korganizer window, not some dialog window. Korganizer quits without asking and loses changes made to the whole calendar by not saving them to disk - this is how I've had my data lost. Norberto, is that the problem you've observed?
That being said, iy is also my opinion that the event dialog box should have a "Do you want to save?" popup hooked up to their close button. I've lead some courses and consultations WRT groupware features of MS Office and MS Outlook, and had some exposure to Lotus Notes. So I've seen several people work their way through a typical calendar application. I'd say I have pretty good knowledge of methods of work of about 90% of corporate groupware users today. It's a common procedure for many people (about 30%) work with appointment and task dialogs in such a way. That is, those people create new or edit a task/appointment, then type something in, then click the close button. They EXPECT the application to ask them whether they want to save changes. Seeing that it doesn't ask, they would probably assume it has been saved without asking (about 60% of users) or check whether their work was unsaved and lost (about 40%). Norberto is apparently among those first 60%, and he is right to expect the application to care for his data instead of dropping it on the floor.
On Tuesday, 20. July 2004 12:51, aleksander.adamowski.kde@altkom.pl wrote: > 2004-07-20 12:51 ------- That being said, iy is also my opinion that the > event dialog box should have a "Do you want to save?" popup hooked up to > their close button. Okay, then feel free to reopen the bug report, but please mark it as wish, not as a bug. Reinhold -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/Pp1TqjEwhXvPN0RAg8PAKCAr+SOWhFZKakYvcYaDb27xv0RQACdGGve n1scCaPKBZZBE3QutyD+YPg= =C/aI -----END PGP SIGNATURE-----
Exactly. I'm talking about the event dialog box (yes, I know my English sucks; I'm sorry about that.) It should ask you "Do you want to save?" when click on close. The way I think it should work is this: * Click on OK -> Save event and close. * Click on Apply -> Save event. * Click on Cancel -> Don't save and close. * Click on dialog's close (X button): IF modified: ask "Do you want to save?" IF YES: Save I'll re-open as a wish.
Errr... "Houston, we have a problem": How do I re-mark this bug as a "wish" ?
Changing Severity to "wishlist". Reinhold
*** Bug 72365 has been marked as a duplicate of this bug. ***
Reassigning all KOrganizer bug reports and wishes to the newly created korganizer-devel mailing list.
As explained by Reinhold and Cornelius, this wish will not be granted.
I understand that modifying the basic behaviour of KDE dialog boxes for this single case is out of the question. However, please note that the original subject of this bug says nothing about dialog boxes or lack thereof. Maybe if dialog boxes cannot satisfy the requirements for fixing this bug (yes, it's a bug - note that in user centric design a bug is everything that is unexpected and unwelcome by the user, regardless of technical details), then the solution is to use some other type of window in this case instead of a dialog box? In my opinion closing this bug without user issues being addressed just because dialog boxes are unfit for this purpose is not appropriate. It's not a commandment cast in stone that the dialog boxes must be used for appointments. If you look at e.g. MS Outlook (which is unfortunately a kind of a design standard others try to imitate), appointments are separate document windows with rich logic and they ask the user for saving changes when they are being closed. Based on this justification, I reopen the bug and suggest forgetting about the dialog box issue and focusing on fixing the problem that the user experiences, switching from dialog boxes to something else if that's required.
I have no permissions to reopen, but I strongly suggest that it be reopened, as the issue is still valid and fixable. The discussion only revealed that fixing it might be more laboursome than initially thought.
I'm re-opening this. And I have code ready to commit... well sort of. We have a few choices: 1) *always* ask if the user really wants to close the editor 2) *always* ask if the user really wants to close the editor, but put on a "don't ask me again" toggle 3) only ask if the user wants to close the editor if any changes at all have been made to the data Typically, a real editor goes with option 3. But that isn't so easy to do in a data entry dialog. So, for now, I'm tempted to go with option 1. Are there other opinions?
SVN commit 896105 by winterz: Always ask for permission to close the incidence editor. Do not backport this -- it is a new behavior, but not a new feature. BUG: 74439 M +36 -43 koincidenceeditor.cpp M +7 -4 koincidenceeditor.h WebSVN link: http://websvn.kde.org/?view=rev&revision=896105