Change a4fea05a43b8fe57b9f43afeb6ed6bd88601c053, Reduce verbosity while reloading

[Andreas Pakulat]

Hi,

On Mon, Aug 20, 2012 at 2:29 AM, Aleix Pol <aleixpol at kde.org> wrote:
> On Fri, Aug 17, 2012 at 8:33 PM, Andreas Pakulat <apaku at gmx.de> wrote:
>> On Fri, Aug 17, 2012 at 6:56 PM, Milian Wolff <mail at milianw.de> wrote:
>>> Well, I'd consider this more of a side-effect than a feature that
>>> forces us to workaround the UI with things like Reload All. Also if
>>> you wanted that, the only you'd have to do is to modify the file...
>>
>> I think we could offer this as an option to the user. We should
>> definetly do a reload-all automatically if the user does a git
>> checkout or something similar inside the IDE, but if files are
>> modified outside of kdevelop you cannot know wether that was
>> intentional or not so kdevelop shouldn't reload automatically (unless
>> the user explicitly decided to do that by setting an option) since it
>> means unrecoverable data loss in the worst case which is the worst
>> thing that can happen to any of us.
>
> I agree, on the other hand if this happens, it's not KDevelop's
> responsibility (if it happens outside KDevelop).
>
> For example, if there's data loss, it will be only recovered in the
> opened documents not the whole project. Should we recognize "make sure
> the data is preserved" as a use case for "opening a file"?

I think KDevelop should simply try to get out of the way of the
developer, if it knows the user did something. So not asking for
reload, but doing so automatically after doing some git-action in
KDevelop or something else in the GUI is what a user expects. However
when KDevelop cannot know why a reload is triggered it should simply
ask, it doesn't have enough data to decide itself (unless there's a
config-option telling it to always auto-reload). The usecase is not so
much "make sure data is preserved", but rather "don't throw data out
the window unecessarily".

FWIW, I don't think any editor-developers consider the use-case of
avoiding the reload to force-save the editor contents over the changed
on-disk contents an actual use-case. Its just a matter of being a bit
more defensive when data can go down the sink which is something that
people like about the editor every time they happen to get into the
situation of an accidental git checkout -f or similar.

Andreas