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

List:       kde-look
Subject:    Re: kde's future
From:       "Friedrich W. H. Kossebau" <Friedrich.W.H () Kossebau ! de>
Date:       2001-01-10 11:30:07
[Download RAW message or body]

"Friedrich W. H. Kossebau" wrote:
> rik@kde.org wrote:
> > #if Friedrich W. H. Kossebau
> > > * automatic saving on leave as default basic version control could be
> > > reached by having an option to revert to file's state of opening time
> > > (autobackup uses temp-file with automatic restortion if needed), and
> > > undo buttons
> >
> > Yes. I remember discussing this a while ago. I wish I had time to work
> > on it :(
> >
> > > * copying/moving by dragging and dropping an document symbol (see
> > > khexeditor!) from the toolbar opens the question what to do if file is
> > > copied and content in app has already changed.  should be directed to
> > > the user :-)
> >
> > Probably copy the file in its current state. I think that would
> > fit the Principle Of Least Surprise (one of my favourite principles.)
> 
> :-) What I think of is that I happened to see many people (including me
> in my early steps) to use one 'finished' document e.g. a letter as a
> template for another. I did this by opening the existing document and
> starting immediatly to make the needed changes. Then I stopped very
> short in front of the save icon (not always :( and went to do a "save
> as..."
> 
> This is a very bad behaviour but it seems that people somehow divide the
> actual loaded document from the saved. The reason may be in 15 years of
> miseducation by badly designed standard software. But those peolpe exist
> and must be helped. Because of that I would suggest to have a dialog
> quering when copying (moving is problemless) whether to save the actual
> state to the original file as well. In this case it should be cleared
> which file is used for further work. Maybe I did the copy to have a copy
> to show to someone an intermediate state, after that proceeding with the
> original making it a mess again ;-).
> 
> Hm. I suggest to reduce this to one question whether to take the copy as
> new document base. If the user rejects this he only wants a print of the
> actual. If he agrees what other reason could there be then him stating
> he wants to keep the original file in his original state. For different
> needs there could be a command "sync" (not save!) that does write the
> actual working state to the actual base.

Got another idea: offer an option in RMB menu "open as copy" or
something what works the way templates work: first ask for a new file
name, then copy and open the copied file with the app. Problem would be
how to be able to make it possible to also offer the user which app to
use. A first suggestion I have is to simply doubling the "open" and
"open with" menu items, one for the original like it is now, one for a
copy of that original.

But this would be a safe way to prevent from overwriting old files.
And quicker then first copying and renaming by hand. 

BTW: has there been thought about extending actions on mimetypes? Like
not only defining what command to use to open it. But to view
(readonly), work (readwrite), print (readonly), convert to (readonly),
...
 
At least differing between view and work would prevent a lot of
accidently changes. So the app could be told by flag what mode to start:
readonly or readwrite. If the user decides to work on he would have to
tell explicitly the app to get in write state. Could be solved by
offering a toggle button (->khexeditor)

Friedrich

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