[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    automated user CVS
From:       Ralf Nolden <nolden () kde ! org>
Date:       2001-08-24 13:57:43
[Download RAW message or body]

Hi there,

while reading some other mailinglists *grin* I fell over the subject that on 
a System the user didn't know about what saving was when asked to save all 
files to shut down the system. The system in effect did all the saving from 
the user, thus didn't bug him with questions etc.

Now, this brought up two questions for me:
a) How can we imitate that to a *certain* extend, not completely (because I 
think offering to save a file is a good thing (tm) in general)

b) in KOffice, or at least KWord, we need a change tracking system so editing 
can be done between the author and a proof-reader by erasing certain parts 
and the author can review it again and comment on that or change it again. 
Generally that emulates a kind of CVS, in effect it is version control for 
word-processing like StarOffice or MS Word has

While reading the german linux user magazine that covered CVS a while back by 
an example how to set up CVS locally for working on something, the writer 
(our all beloved Trish) used a report in TeX as an example.  Apparently, 
version control is a very valid and useful thing not only for the developers 
like we do but also for the average user. The "but" part here is that the 
average user should be offered the pro-side of this without being hassled by 
the con-side, that is setting up the server, import and keeping track of this.

Maybe it's just a stupid, silly idea of me and it can't be fully realized 
*ever* :) but I think an automated user CVS could be done by using CVS 
withouth the user's notice. That would require an automatic CVS library that 
does the scheduling with the applications and import it to a local user's 
repository, all without notice of the user. That way, we could even 
advertise: On a KDE system, you're even able to restore the last saved status 
of your document even if you completely destroyed it. And not by a ~file 
that's laying around. Also, the version control for koffice documents could 
be merged with that functionality, so any non-binary data files that any 
application that's yet to write could utilize as well is proved (although I 
guess that's the hardest part to do here).

As an idea, I could imagine a demon that's interacting with dcop and do the 
actual work of importing, updating etc etc and even pop up and notify an 
application after it is restarted from a crash that there's a list of 
documents available to restore and that can be invoked over dcop. 

Comments ?

Ralf
-- 
We're not a company, we just produce better code at less costs.
--------------------------------------------------------------------
Ralf Nolden
nolden@kde.org

The K Desktop Environment	The KDevelop Project
http://www.kde.org		http://www.kdevelop.org

[prev in list] [next in list] [prev in thread] [next in thread]