Version: (using KDE KDE 3.5.8) Installed from: SuSE RPMs Reasons: a) kate is well designed, tested etc. dialog b) it is better to focus on one UI than each time reinvent the wheel b.1) user does not have to learn again new things and how app works c) it is kate embedded after all so it is bad to replace UI user sees in Kate itself (standalone)
KDevelop does not only embed kate, it embeds other KParts as well, which can be editable too. Thats why we have our own notification dialog, to be consistent across all KParts we embed.
Andreas, can those others parts be: * reloaded * overwritten * (changes) ignored ? If yes, it would be much better to reuse this dialog from Kate. Currently there are four _different_ notification dialogs for doing _one_ thing. This is not good at all. Kdevelop not only uses its own dialog it also changed the workflow of accepting user decision -- this is also bad.
The whole point is that kdevelop wants to have the notification, but it doesn't want to rely on the KPart it uses to implement it. That way we are sure we always have the notification for external changes. Its not a big deal to use the same dialog as Kate(part) does here, in fact I think it would be good to have a namespace function in kdelibs that does the KMessageBox call and returns the dialogs value. Then all kde apps/kparts that want to provide such a notification message have the same. However I'm not quite sure I understand how kdevelop changes the workflow? Can you explain that a bit more.
> The whole point is that kdevelop wants to have the notification, but it > doesn't want to rely on the KPart it uses to implement it. That way we are > sure we always have the notification for external changes. But Kate has always notification. So you can rely on its mechanism. > Its not a big deal to use the same dialog as Kate(part) does here, in fact I > think it would be good to have a namespace function in kdelibs that does the > KMessageBox call and returns the dialogs value. Hmm, so maybe reopening...? :-) > However I'm not quite sure I understand how kdevelop changes the workflow? > Can you explain that a bit more. In Kate, on file modification, users answer once and the decision is final. In Kdevelop answer is not answer per se, but rather setting the status. So when you save the file you will be asked again. However this is bad, because the time elapsed between those events can be short period and can be long period -- and it is always bad to ask somebody "hey, this thing that happened half an hour ago, you remember, what to do you want to do with it?". And I bet that when you writing code you are focusing on the code, so after half an hour you will be rather puzzled what is going on.
> But Kate has always notification. So you can rely on its mechanism. Yes, but as I said we can't rely on the other kparts we embed. > Hmm, so maybe reopening...? :-) No, open a new wishlist item for kdelibs. > In Kate, on file modification, users answer once and the decision is final. > In Kdevelop answer is not answer per se, but rather setting the status. So > when you save the file you will be asked again. However this is bad, because > the time elapsed between those events can be short period and can be long > period -- and it is always bad to ask somebody "hey, this thing that happened > half an hour ago, you remember, what to do you want to do with it?". > And I bet that when you writing code you are focusing on the code, so after > half an hour you will be rather puzzled what is going on. Sorry, I still don't understand the differences. I'll try to test both later tonight. But the notification in KDevelop is only executed when you actually save to the file, if you never do that there's no point in notifying the user.
> > Hmm, so maybe reopening...? :-) > No, open a new wishlist item for kdelibs. Ok, but what is my wish then? Incorporating Kate notification dialog into kdelibs? > But the notification in KDevelop is only executed when you actually save to > the file, if you never do that there's no point in notifying the user. Nope. You see one dialog when the modification takes place and the second one (different) when you try to save the file. Compare it to Kate -- Kate has far more elegant solution (well, simply common sense).
On 03.01.08 17:39:59, Maciej Pilichowski wrote: > > > Hmm, so maybe reopening...? :-) > > No, open a new wishlist item for kdelibs. > > Ok, but what is my wish then? Incorporating Kate notification dialog into kdelibs? Exactly. Its just the dialog that should move to kdelibs, not anything of the detection code... > > But the notification in KDevelop is only executed when you actually save to > > the file, if you never do that there's no point in notifying the user. > > Nope. You see one dialog when the modification takes place and the second one (different) when you try to save the file. Aah, indeed, one is one too much there :) If you don't mind I'd like to ask the devs first whats the reasoning for that and depending on the answer I'll open a bugreport for removing the "automatic" notification dialog. Ok? Andreas
Actually I changed my mind. KWrite in KDE4 has similar behaviour and thats good. KDevelop notifies you when an external change happened and you can choose to ignore that change for now or reload the file. Later on when you chose to not reload the file you're warned again that you might overwrite changes on disk.
> Later on when you chose to not reload the file you're warned again And that's bad design. Note -- _LATER_. If you modify several files, instead of useful information you will drown in a mess. Compare it to Kate -- you make up your mind once, user is not troubled with remembering what was modified, why, etc.
New report: https://bugs.kde.org/show_bug.cgi?id=155149
Well, you make up your mind in KDevelop once as well. Either you reload the file or you defer the decision until later. The latter makes sense when you're not yet sure wether you want to drop your current work or not (i.e. if you actually going to save or not).
Andreas, ok, you are right -- after all if user does something stupid it is her/his problem. So, the main concern now for me is unification of this dialog (plus renaming "cancel").