GSOC 2012 Project Manager Core

This is the official 2012 Google Summer of Code Scribus Project Manager Project page.

Defining the Core functionalities of Project Manager:

Previously, JLuc and Malex discussed that it is important to define the core functionalities of PM for its success through GSoC. As discussed on Apr 17 on irc,

<JLuc> Its important to define the core functionalities of PM.

<JLuc> Final definitive proposal of PM.

<JLuc> Is it necessary to split PM into 2 or not?

<JLuc> Good solution requires exploring, thinking, designing :All PM students,scribus users and mentors please take part into this.

<baazigar> A fileformat to store shared resources and attributes?

<JLuc> Its an option.

<vox> just add an attribute to styles, palettes etc. that says fromMaster="masterdoc" and write some update code.

<vox_> baazigar: since scribus docs already store all this stuff, why not reuse it?

<baazigar> would it require the fileformat be changed slightly for a slave document?

<vox_> baazigar: it shold at least know its masterdoc

<JLuc> that's how i imagined it could be : defining a masterdoc

<baazigar> this would be a lot easier than making a new fileformat !!

<MrB> ok.. so.. i think we need to define this project a bit better within the team.. firstly, i see a project management module initially not modifying the scribes docs.. but being a resource manager, collector, etc.. theres significant work there.. then there is the side where the docs might actually get modified where they could inherit (like you have been saying) from "Project Master" master page etc

<JLuc> this inheriting can be either 'physical' (copying attributes from master to slaves) or 'virtual' (getting access to data through links, when needed)

<baazigar> virtual would be better

<MrB> but harder.. and risky for existing docs

<baazigar> there are too many choices !

<MrB> no.. one just needs choosing that doesn't lock scribus into a corner

Possible core functionalities

Implementing two types of documents in the Project Manager: MasterDocs and SlaveDocs.

Whenever a new SlaveDocument is created, it will be the exact copy of some MasterDocument(the sla that rules and defines a book in a project manager). Whenever some change is done to a MasterDocument, the change will show in the SlaveDoc as well. This would be done by copying attribues from master and incorporating in the slaves. Later, some private attributes can be added to the slavedocs(as every page is different in a book).

Points to be discussed regarding inheritance:

1)Can there be two or more masters? 2)Can a slave have many masters? 3) A slave inherits from another slave?

There would be only one masterdocument. The masterdocument will store all masterpages & styles.

If a there are different types of slavedocuments like diffent chapters, which have different layouts, they have to store the common attributes in the masterdocument. Masterdocument will get all edits and slavedocs will copy them.

Should something be added or removed from the shared attributes list?

masterpages, styles, images, tables, scrapbooks, frames, numbering variables,colours

Would pdf generation be very different from the existing one?

Create all updated PDF + if "book" option is specified : call pdftk if present so as to combine all PDF into a single PDF

Do we still need to divide the PM into 2?

If somehow equal and orthogonal timeline can be designed.

IS IT NECESSARY TO CHANGE THE FILEFORMAT OF SLA TO INCORPORATE THE PROJECT MANAGER?

The point of this discussion is How will the master know which are the slaves? or How will slaves and master link? or How will the slaves know from where their edits come(which is the master)? Possibilities:

• No change in sla

A separate folder will store all the documents of type sla only.This folder will be contain slaves as well as the master. When Scribus opens this folder, it doesnt know which is the masterdocument. Either the user will define the masterdocument here or the masterdocument will be named as masterdocument.sla so that PM function know their master.

• No change in sla + another file for pm

A separate folder which will store master and all slaves + a txt file. This txt file will have information about which file is a master and how many slaves are there and where are they stored(if not in a common folder).

• Little changes in sla fileformat

All slaves store a link which tells them where their edits come from(masterDocument).Correspondingly, the masterDocument will store the link to its slaves and will call the functions required to update the slaves whenever there is an edit.

• A separate fileformat for the PM

When some huge book has to be made, this fileformat will be used, otherwise sla is sufficient. This new fileformat will store all the slaves and master + additional information.