View Issue Details

IDProjectCategoryView StatusLast Update
0003459ScribusGeneralpublic2006-03-21 22:18
Reporterchristoph_s Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status acknowledgedResolutionopen 
Product Version1.3.4cvs 
Summary0003459: Enable saving of only parts of a document
DescriptionThis will become important in the future for collaboration purposes, but it will provide some advantages without collaboration as well. Say, if someone has finished working on a text in a frame but work was going on on vector or bitmap graphics in between, one could save the text work and continue editing other objects. In case the user wants to undo all changes to these objects, he could simply do a "Revert to saved".
TagsNo tags attached.
Patch

Relationships

child of 0001925 acknowledged Multiple users sharing one open document 

Activities

ringerc

2006-03-18 09:11

reporter   ~0009360

I'm not sure I understand, but I have the feeling that the plans to save the edit/undo history in the file would do what you want, yes?

If not, can you explan a bit more? I'm having trouble understanding why you'd want to save only part of the file, or how that could work.

christoph_s

2006-03-20 22:53

administrator   ~0009397

This feature could certainly use the undo/redo code to some extent, I assume. Here are some further explanations on what I intend:

a) Single user: Large document with many items, some finished, some not. Once the user decides he has screwed up some parts and better start from scratch, he can save those items that are to his satisfaction. Instead of undoing hundreds of steps for all the other items, he could simply "revert to saved".

b) Multiple users working on a single document: Each user can edit and save his work separately, without having to save the document as a whole. This will prevent overwriting changes made by others by mistake.

cbradney

2006-03-20 23:18

administrator   ~0009398

Sounds like a way "out of the box" but generally incorrect solution to two different issues solvable in better ways. The current file loader and saver code could never allow this anyway as it must read/write it all.

christoph_s

2006-03-20 23:31

administrator   ~0009399

>>> Sounds like a way "out of the box" but generally incorrect solution to two different issues solvable in better ways.

Well, if this can be achieved in better ways, fine. Close this one any time, if you like. I only thought this was a quick way to sort out what should be saved and what shouldn't.

>>>The current file loader and saver code could never allow this anyway as it must read/write it all.

But a rewrite is on the roadmap, isn't it?

cbradney

2006-03-20 23:51

administrator   ~0009401

A rewrite is on the roadmap, but its not exactly intended to allow this.

Have you seen any other apps that provide a reasonable solution to the issue you point to?

ringerc

2006-03-21 13:20

reporter   ~0009411

>>>The current file loader and saver code could never allow this anyway as it must read/write it all.

>> But a rewrite is on the roadmap, isn't it?

Yes, but that's WAY beyond what will be done to rewrite the load/save code. Saving in segments would be ... er ... nasty. Very. You'd essentially need to load the doc on disk into a DOM, merge the changed bits, and save it again. Lots of work, and for what I think is little or no benefit.

I think this is a wrong approach that attempts to solve some (possibly related) problems, but will not succeed. I am not persuaded by any of your use cases:

(a) is better solved by undo (remember that Scribus supports per-item undo, and it'll be improving throughout the 1.3.x series, so you need not lose all changes to restore one. Later it may even be possible to undo a single change in the middle of the history of one object, eg undo a move without undoing text changes in a text frame).

(b) is IMO better solved by using a document server that keeps track of history, and using the undo framework - with shared undo history that keeps track of what user did what - to manage things.

To my mind, partial save would be lots of extra work as well as lots of complexity for both developer and user. Given that I think it'd be better solved by using the undo system and extending it as described above - for less work, less developer pain, and much less user confusion - I don't see the value here. It's possible I'm missing your point, but if so Craig Bradney seems to be missing it the same way.

Can you explain what you'd get out of this that you would not get out of per-item undo that's saved with the file, and from a collaboration server that uses that facility?

christoph_s

2006-03-21 22:18

administrator   ~0009415

>>>Yes, but that's WAY beyond what will be done to rewrite the load/save code. Saving in segments would be ... er ... nasty. Very. You'd essentially need to load the doc on disk into a DOM, merge the changed bits, and save it again.

OK, I understand that this would probably mean breaking a butterfly on the wheel.

As for a): What about a tree view in the undo dialog, showing all items and all actions, something like in the document outline, but specifically designed for undo/redo? In this dialog it should be possible to reset an object to "last saved", e. g. per context menu. An alternative (or an addition) would be something like the navigator in SO/OO.o that shows all objects sorted by text frame, picture frame etc. If one could reset the editing status there and select multiple items at once, this could also speed up work.

As for b): Using a document server would be fine anyway. But in this case Scribus must be able to support external objects, because it's not just the pure content that matters, but also formatting. It's not enough to edit text, but the external object would also have to save information about kerning, tracking, distance to frame etc. If that were the case, my original b) would be meaningless.

Issue History

Date Modified Username Field Change
2006-03-18 00:00 christoph_s New Issue
2006-03-18 00:18 jo-hannes Relationship added child of 0001925
2006-03-18 09:11 ringerc Note Added: 0009360
2006-03-18 09:12 ringerc Status new => acknowledged
2006-03-20 22:53 christoph_s Note Added: 0009397
2006-03-20 23:18 cbradney Note Added: 0009398
2006-03-20 23:31 christoph_s Note Added: 0009399
2006-03-20 23:51 cbradney Note Added: 0009401
2006-03-21 13:20 ringerc Note Added: 0009411
2006-03-21 22:18 christoph_s Note Added: 0009415