TODO list for 2.0 (7/5/2001)

[W. Tasin]

F at lk Brettschneider wrote:

>Jens Zurheide wrote:
>
>>Tuesday 08 May 2001 06:42 W. Tasin
>>
>>>Roland Krause wrote:
>>>
>>>>--- "F at lk Brettschneider" <gigafalk at yahoo.com> wrote:
>>>>We should check when we switch views, or when we attempt to save and
>>>>thus would overwrite the file. But how do you check whether the file
>>>>was changed? Is there a way to compare and save file modification time?
>>>>
>>>IIRC this was done by Sandy on the 1.4 branch.
>>>
>>>IMO you should check the modification outside of the buffer ONLY if you
>>>would destroy the newer modification.... (so only on Save this file or on
>>>Save All)
>>>
>>>Please don't do this on switching views...
>>>
>>>Falk: The way to check it:
>>>On loading the file to memory you should also get the time and date from the
>>>file on disk (QFileInfo I guess) and remember it (in a memory structure or
>>>similar), on file save these two values will be compared again. If
>>>something has changed give a warning...
>>>if not, save it and remember the new time and date from the file (again
>>>QFileInfo, never system time).
>>>
>>I would favour if the check is performed on changing the views and maybe even
>>on editing. What if a file really changes outside the editor and you do not
>>notice it, you start changing it in the editor and finally you want to save
>>it? You will most probably loose time. (The time for comparing two timestamps
>>against each other should not be the problem.)
>>
That's also ok!
Apart from the fact that "saving" HAS to be included, because it would 
destroy the other version of the file:
Think of this situation:
You are editing a file (without saving it and changing the view), now 
you go to get a cup of coffee, while somebody changes your file and 
saves it, being remotely connected to your machine.
Now you returned and the first action is (noticing you haven't saved) 
"Saving All".

I guess the best method would be checking multi-threaded with a timer, 
but to find the right algorithm is a kinda hard stuff (think of the 
problems we had with "Autosave").

Please consider these points, too:
Checking almost everytime makes it necessary to have a non-loosable 
connection to the media. On hard drives this won't be a problem, but on 
removable media (floppy or a better example would be zip) or remote 
filesystems like NFS (if temporarily down or unmounted/remounted) it would.


So

> (The time for comparing two timestamps against each other should not be the problem.)

can be a problem if you have to await a network timeout.

Other questions are:
On which conditions the checking would be suspended?
How long would the checking be suspended?

I think apart from the problem "When the checking will be done?"  the 
more important question is "What should happen, if a problem occurs?"

I think much of the problems can be handled if
- there is only one warning for all changed files (not one message for 
one changed file)
- the warning message gives the possibility to save the file(s) on 
another location.

>>
>Well, thanks a lot for the hints mates, my today's decision would be to
>implement it like in MS Visual C++ 6.0. MSVC takes a check for all open
>files whenever the mainframe window has got a focusIn event. And I think
>that is the best way. You change a file outside KDevelop and after that
>you switch back to KDevelop where it will be noticed _immediately_. And
>it means to avoid unnecessary checks. What do you think about this
>suggestion?
>
I think this is ONE solution and a good compromise between checking too 
much and being noticed in an acceptable time period, but take care 
saying: _immediately_...

on Windows certain situations are difficult to retrieve, like:
switching to another console and editing file with the vi ;-)
or connect to the machine by telnet and editing a project file in a 
common directory for more than one user.

So focusIn won't change, but the file has changed.
Still insisting on: AT LEAST "Saving..." has to check the timestamps.

>
>
>BTW: Hmm...In Toplevel MDI mode, it is necessary to check the open files
>with every focusIn event of any toplevel view. Additionally, we could
>use DocViewMan::slot_gotFocus as central point.
>
>Cheers,
>F at lk
>
>_________________________________________________________
>Do You Yahoo!?
>Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>-
>to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
>unsubscribe »your-email-address«
>

Ciao

Walter

-- 
  The KDevelop project: tasin at kdevelop.de - http://www.kdevelop.org
--
oohhh sveglia.... il mondo e' ammalato, ma x colpa di chi.........
(Zucchero)
:-------W. Tasin, FB 04,FHM-------------------PGP-KeyID:0x7961A645---------:
<Key-Fingerprint: 1610 835F 0080 32F4 6140  6CF7 A7D0 44CD 7961A645>
<http://wwwkeys.pgp.net:11371/pks/lookup?op=index&search=0x7961A645&fingerprint=on>




-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«