Talk:GSoC 2012 Student Proposals: Difference between revisions
No edit summary |
No edit summary |
||
(3 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
<big>'''Defining the Core functionalities of Project Manager:''' | |||
</big> | |||
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 | |||
==<big>Possible core functionalities</big>== | |||
====Implementing two types of documents in the Project Manager: MasterDocs and SlaveDocs.==== | |||
Whenever a new SlaveDocs is created, it will be the exact copy of some MasterDoc. Whenever some change is done to a MasterDoc, 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? | |||
====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?==== | |||
====Do we still need to divide the PM?==== | |||
I dont think so. | |||
====how the UI will work==== |
Latest revision as of 16:16, 18 April 2012
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 SlaveDocs is created, it will be the exact copy of some MasterDoc. Whenever some change is done to a MasterDoc, 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?
masterpages, styles, images, tables, scrapbooks, frames, numbering variables,colours
Would pdf generation be very different from the existing one?
Do we still need to divide the PM?
I dont think so.