[scribus-dev] Collect 4 Output file permissions and behaviour

[JLuc]

I've met this "changing current directory" behaviour
and i allways have been happy with it in my workflow,
but i allways have been uncertain about it :
"Has the current file changed to the collected one
or am i allways working on the previous one ?"
was the question. It required some more steps to check.

A warning should be issued when the file being edited becomes the collected file,
or the name of the option could be changed to something reflecting this behaviour
more clearly, like "Collect and save as...".

JLuc

Le 11/12/2013 22:15, Craig Bradney a écrit :
> On 11/12/2013 7:45 pm, Mark Heieis wrote:
>> Hi Craig,
>>
>> I think I narrowed down the errant behaviour.
>>
>> First off, the patch code does work. Starting from opening a file and then calling c4o worked well.
>> All of the c4o documents maintained the original src file permissions. So I think that solves the
>> file permissions problem.
>>
>> So that leaves the errant behaviour and why. The behaviour I saw was due to me deleting files in the
>> destination folder mid-stream while experimenting with scribus/c4o in debug mode. In playing with
>> the code and scribus, I didn't notice that once c4o was executed, the scribus document context
>> changed from the document source directory to the c4o output directory. So what was happening when I
>> re-executed c4o, scribus used the c4o destination as its source, which of course failed when I
>> deleted the image directory or images files (ie no "source" files). (You can see this context change
>> in the title bar for the active document)
>>
>> The question is: should the document directory context be changing when c4o is executed? In my mind,
>> the c4o output shouldn't be used for document changes. What is the expectation? If I was making
>> changes, I'd want them in my source files and then re-execute c4o as needed, otherwise the chance of
>> losing edits would be great.
>>
>> Regards,
>>
>>
>> mrh.
>
> Hi Mark
>
> Thanks for looking into it, I will commit that code.
>
> The behaviour its always had regarding the saving - but it doesn't have to. I think its likely that
> way as that was the best way to write the SLA file to the destination directory. If we can execute
> the save operation and not change the location, I do agree that makes more sense. I'll have a look.
>
> thanks
> Craig
>
>