On Thu, Mar 4, 2010 at 3:21 PM, Pavel Sanda <[email protected]> wrote:
> John McCabe-Dansted wrote:
>> On Thu, Mar 4, 2010 at 6:05 AM, Pavel Sanda <[email protected]> wrote:
>> > John McCabe-Dansted wrote:
>> >> Below I present very preliminary support for warning the user when
>> >> their LyX file is externally modified. Does the following approach
>> >> sound worthwhile?
>> >
>> > this has even some bug number. the reason why its not implementeed
>> > yet is that its not easy to find a point where to trigger such
>> > check. for example you definitely dont want it to be checked after
>> > each typing keystroke inside markdirty. you avoided it, but for the
>> > price that you'll never check this once editing file started.
>> > also i would like to have this check on one point not at 10 different
>> > places...
>>
>> Would checking in two or three places (as proposed) seem excessive?
>
> concerning the fact how rarely will be the check in previous patch
> reached...
Perhaps, but that is IMHO the most important case. If the document is
externally modified and
1) The buffer is not dirty: then this isn't really a problem, the user
might not even intend to edit the document.
2) The buffer is dirty: It is too late to avoid the need for a merge;
a merge will be required anyway. notifying the user earlier rather
than later may make the somewhat easier though.
3) The exact moment the buffer is marked dirty: This is the one case
where we know there is a problem and also that the user can resolve it
without the need for a merge, just by reloading the document.
There is another possible case: where more than one copy of LyX has a
modified copy of the same file. This is less of an issue on programs
that only allow the user to open one process per session.
Also, I was thinking it may even be worth making a copy of the
original .lyx document so we can do a proper 3 way merge. All of the
lyx files for my thesis, including weird test files, is under 10MB.
Even if I loaded all of them into memory and modified each one it
wouldn't really matter.
>> >> 1) Checks every 1 minute if the file has been modified (Even if a
>> >> merge is required, the sooner the easier)
>> >
>> > that is one possibility. i felt somewhat uncomfortable to have such
>> > asynchronous events in the code, but now i realized it might be possible
>> > to attach it to the code for automatical file saves...
>> >
>> > secondly it should be possible to turn it off (maybe even by the
>> > automatical save option?). there are rare but regular reports
>> > about problems when file are saved over network, and it should
>> > be possible to avoid automatical saves/polling for such users.
Sure.
>> Checks if the file is modified when the Buffer gains *focus* (like kwrite)
>>
>> This presumably could be done by listening for Qt "focusChanged"
>> signals, though I haven't checked how kwrite does this.
>
> i see, focus-trigger is a better idea. still i feel bit uncomfortable.
> in case the network connection disconnects for a while you will freeze
> lyx until it gets better again? another place coming into my mind will
This seems like something that would be trivial to move into a thread.
Take a checksum of the document in memory and then let a thread check
the checksum of the document on disk. If we only have one thread for
this purpose then the network freezing could "automatically" disable
further checks (its a feature, not a bug).
> be the code for checking if the buffer can be reverted - its get triggered
> eg every time you launch file menu. it already touches the active buffer
> so no additional harm.
That could possibly also be moved to a thread I guess, though that
leaves open the issue of what to display until the network responds.
Presumably weird thread bugs are unlikely to occur if we only
communicate via signals, avoiding any access to shared objects and
memory.
> sorry to be so picky about this, but i clearly remember the frustration
Don't worry I have other things to do. I don't need to implement it
right this minute. July would be fine. :)
>> Well, for example, when I start LyX I run (attached)
>> svn-up-to-date.sh &
>> Polling the server every 30 minutes could reduce further the
>> possibility that a merge is needed.
>
> you mean this really works for you? to my knowledge svn info touches only the
> local checkout not the archive on server.
Yes. From "svn help info":
-r [--revision] ARG : ARG (some commands also take ARG1:ARG2 range)
...
'HEAD' latest in repository
--
John C. McCabe-Dansted
