[scribus-dev] Collect 4 Output behaviour

[Mark Heieis]

Thinking from a purely a usability perspective: The current 
implementation would be hard to train for and use. especially from a 
high volume, "multi-editor" environment perspective. I could see one 
workflow where the c4o output location is a hot folder, at which point 
the dropped files are now under "system control" and are moved to other 
points for processing, etc. Or the process is that once the files have 
been used, they are deleted to indicate a completed project, etc. That 
is, no files in the c4o location. So what happens now? Or how does one 
teach a new user or document it? "Edit your files as normal, do c4o when 
you are ready, oh and remember, after you have done a c4o you aren't 
editing your files anymore, even though you still have your original 
files and location... you'll need to re-open your file..."

I think having a utility that packages and collects all of a document 
components into a single location is very useful. I just don't think 
that the file contexts should be changing. Users should be notified 
about unsaved modifications and given a choice on how to proceed, or 
that they need to be saved first, to the original docs location, and 
then have Scribus collect and copy the document components to the c4o 
location.

This still leaves the option of a user opening and using the c4o files 
as a separate action, should they wish. Still, I'd be really concerned 
about losing work/changes. Shouldn't that be a priority: preventing loss 
of work?

I guess I'm treating c4o as a method for packaging,where the persistence 
of the c4o location and files within it are not guaranteed. (Ironically, 
making those output files read-only would almost make sense -- to 
prevent inadvertent changes when a user thinks they are working on their 
source docs)

Just my thoughts.

Regards.

mrh.

On 2013-12-12 00:41, JLuc wrote:
> 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
>>
>>
>
>
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev