Talk:GSoC 2012 Student Proposals: Difference between revisions

From Scribus Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Discussion on how the user interface will work for Project Manager -- [[User:RGupta|baazigar]] 23:07, 5 April 2012 (CEST) ==
<big>'''Defining the Core functionalities of Project Manager:'''
</big>


This is really important because there are many windows in Scribus which have a structure of their own.
Previously, JLuc and Malex discussed that it is important to define the core functionalities of PM for its success through GSoC.
We need consistency in the UI of Scribus.
As discussed on Apr 17 on irc,
So the discussion will be on how to make the UI of Project Manager consistent with other parts of UI.
 
<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?

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